Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Why is one tab not being imported as a dependency?

in Questions Posts: 1,187

I have project A that’s using project B as a dependency.

Project B has four tabs other than Main.

In the dependency list it only says three tabs are available—any clues as to why?

Tagged:

Comments

  • Posts: 143

    the main tab is not included in dependencies and if i remember correctly only tabs with classes are included, and only classes are passed in the dependency, so any raw tables or functions are not going to be referential either

  • Posts: 2,268

    @skar - are you sure about that, I’m sure I have been able to use tables, stored in one tab, in a dependency. But, I may have included them in a function and called the function to initialise them.

  • Posts: 1,187

    Terminating and re-launching Codea fixed the problem. Odd.

  • Posts: 2,268
    @UberGoober - had you just installed/upgraded Codea or a beta. The first project run generally crashes so it could be related to that.
  • Posts: 1,187

    @Bri_G I had upgraded but about half a day ago.

    I added the fourth tab after the project was initially created--it started with three tabs (not counting Main), and then I worked in another project, and then before using the first one as a dependency I went back and added a fourth.

    I kept opening and closing the project I was using as a dependency, and the project I wanted to use the dependency in, to alternately make sure there were actually four tabs and that only three were showing up as available in the dependency list.

  • dave1707dave1707 Mod
    Posts: 9,287

    If a tab is added to a project that’s already checked as a dependency, Codea has to be closed and reopened for that tab to show up. Also, a tab can have anything in it and it will show as a dependency. The only tab not use is Main.

  • Posts: 1,187

    @dave1707 that makes sense, but I checked and unchecked the dependency and it didn't refresh.

    I also unchecked it, closed the project, and reopened the project, and the dependency tabs didn't refresh.

  • dave1707dave1707 Mod
    Posts: 9,287

    @UberGoober Not the project, but Codea itself.

  • Posts: 143

    oh this is maybe why i thought it's not importing other files, i'll have to test it out later

  • Posts: 1,060

    I'm working on some code that is going to make me want more control over tabs in dependencies, or want a better idea than the ones I have. :smile:

    I'm starting to build a set of tools to help with building large Codea apps like my Dungeon. I'll include analysis programs like Dave's recent two that display class, method, and instantiation info.

    I'd like to wind up with a "Making" app that can be linked as a dependency. And the Making app itself is complicated enough to need testing with CodeaUnit or something similar. Presently the little version I have of Dave's program has five tabs, Main, Report, Tests, Sample, and Uncommented. The last three are all part of the testing. So all that I'd really want imported into an app that used these tools would be the Report tab. (Naturally, as time goes on, there'd be more, but there would always be a few tabs, like Tests (and probably its sample data) that should NOT be imported.

    So what would be sweet would be the ability to add a project as a dependency and then select the tabs to include.

    Workarounds:

    There are possible workarounds. I might be able to set up a Making App Making App that included the tests and samples, and let it have the real Making App as a dependency so that the real Making App could include only the "public" tabs. (Maybe there should be private tabs that automatically do not export?)

    If I were to do that, working on the Making App would be a pain, since I'd have to swap projects back and forth to work on the tests and the app, and one does that swap very frequently.

    Or, I could physically copy the public tabs over to a "Released Making App", which would be the one imported. This might possibly be able to be automated. The Released Making App would have a single foothold tab, maybe its main, that would scan the Development Making App for tabs to copy, and then it would read them and write them back to itself. Arrgh. That could almost work ...

    Related Question: If I add a tab to a project and another project has that project as a dependency, does it automatically get the new tab, or do I have to disconnect it and reconnect?

    So, two things: requested feature, select tabs to be included in dependency, either at source or target. And, ideas for smoothest way to do this in the absence of that feature.

    Thanks!

  • edited May 29 Posts: 1,187
    @RonJeffries maybe I’m missing the point but would it work to put the things you want to hide inside a function?

    For example with CodeaUnit, could you take a project like Maker and put its whole CodeaUnit tab inside a function called makerCodeaUnit?

    AFAIK globals created inside a function don’t actually become globally accessible until that function is called, so I think, if you only ever called it from Maker’s Main tab, which isn’t visible to dependencies, the function would effectively hide the Maker version of CodeaUnit from view by any other project.
  • Posts: 1,060

    well, maybe, but the code would still be there, and the tabs. i have 44 tabs now. managing them is tedious, so something needs to be done. maybe one amazing tab full of everything. that'll be messy in its own way ...

  • edited May 30 Posts: 2,268
    @RonJeffries - sounds like War & Peace, is it code in your tabs or data?

    @Simeon - Could you phase dependencies? By that I mean programmatically add and remove dependencies. I have commented, way in the past, that the BBC Micro only had 32k memory but could run quite large programs by 'Chaining' them. By that I mean running sub programs so you could, for instance, have a different chained level for each level in large games.
  • Posts: 1,060

    code

  • Posts: 2,268

    Wow!!!!!!!

  • Posts: 1,187
    @RonJeffries so the problem of managing tabs is paramount and access control is secondary?

    An extremely kludgey but not at all impossible solution would be to create some scripts that read and write the contents of tabs in such a way as to be able to cut and paste any number of tabs into one big tab, as well as decompose a big tab back into individual tabs. That way you could directly control how many tabs you have, and what’s in each one.

    Also I’m assuming you know that dependencies ignore the Main tabs. Meaning another way to perform access control would be to tuck away everything you want to hide in the Main tab of a project.
  • Posts: 1,060

    Yes to both. But ... I only know of two reasons to put the source into the app, and one of them I don't really agree with. The not so good reason is, for example, putting CodeaUnit into the app, which I did for your convenience. Why don't I like that? Because I use CodeaUnit by reference, and in D2, if I need to enhance how it works, it's in the wrong place, my app, rather than in its own project. No biggie, obviously.

    The other reason is to include the code because we likely need to modify it while working in the App. In that case, we don't want it jammed all together.

    If Codea could run two instances -- why can't it -- I'd just keep the Shipping App and the Making App open at the same time. But switching between projects in Codea is tedious. (Two or three whole touches! Who can even tolerate that??? :smile: )

    The more I think about it, the more I think I should keep the making stuff separate, reference it in, and just deal with it.

    Now I have to go request a feature.

  • Posts: 1,187

    I am having trouble picturing the kind of workflow you want to enable. Let me try to sketch it out and you can correct me if you like.

    So let’s say your project is called TheProject, and it has a ton of tabs. You want to have a ton of diagnostic tools that you can use as a dependency. You make a dependency on a DiagnosticProject, and it has all the great stuff.

    Problem one arises when you need to use the diagnostic tools on the DiagnosticProject itself, like CodeaUnit. DiagnosticProject should make CodeaUnit available to everyone else but it also needs to use it on its own. Ideally it could see its own tests but no one else could.

    Problem two arises when you need to add or remove tabs in the DiagnosticProject, because Codea seems like it won’t automatically alert its dependents about those changes. So let’s say there’s a new tool called FPS_Profiler that you add to the DiagnosticProject. Ideally every dependent project could instantly access the FPS_Protiler.

    Problem three arises when you want to modify DiagnosticProject while you’re working in TheProject. This will come up fairly often, especially in the early stages of DiagnosticProject. Ideally you could work in TheProject and directly make changes to DiagnosticProject on the fly—including adding and reorganizing tabs in it.

    And problem four is the evergreen problem of tabs aplenty. TheProject has so many tabs that when you need to switch back and forth rapidly between any two of them you end up spending a lot of time scrolling the tab bar left and right. Ideally there would be a way to find and and switch between tabs more easily and much more fasterer.

    I think there are hacky ways to enable all these things, mostly through the magic of reading from and writing to tabs. It might take some doing but I think it could be done.

    I feel like there are other things you want to do that I’m not getting though.

  • Posts: 1,060

    that's certainly a good starting list. and i need to get started trying things to see what i run into

  • edited June 1 Posts: 2,268
    Don't know what Codea is written, suspect one of C incarnations, but I feel that the need for a project profiler/error trapper has been needed for some time. The current error trapping is pretty good but there are holes which could be filled. But, I believe the best way to do this is with the language that Codea is built in as all of the hooks etc will already be present and accessible by the developers.

    That brings me to my second point - it should be done by @Simeon and his crew.

    Third point - I think it should be a system which is configurable on/off within Codea and core code could be excluded when running through Xcode etc. Present within Codea if needed to remove troublesome issues and final test before issuing projects.
  • Posts: 1,187

    @Bri_G you’re not wrong. And I’m curious if you’ve investigated any of lua’s own error-trapping/debugging tools. They’re not super robust but they can help in some situations. But they’re no replacement for a UI-level debugging/profiling system of course, I fully agree that we could use that.

  • Posts: 1,187

    @RonJeffries as you probably sussed this is what I meant by a hacky way to solve problem 4 (too many tabs).

  • Posts: 2,268
    @UberGoober - unfortunately I'm not that good a programmer, but I have missed a few tools at times, but rather than build our own I think it better if TwoLivesLeft provided them - they probably have most of what we need now. Simple tools like FPS built in would save us time and effort.
  • edited June 1 Posts: 1,060

    i'd suggest that the best idea might be for @Simeon et al. to provide "hooks" in the base implementation, that could do things like call back to user-provided lua functions. then everyone could contribute to developing useful tools. there may already be some built in, but i suspect we need some special ones, such as ability to stop the program, go to the console, then resume.

    there's a lot we could do, i suspect, given some spots to hold on to.

  • edited June 1 Posts: 1,187

    @RonJeffries you are aware that my breakpoints do both those things — use hooks and allow callbacks — no?

    Sure it would be swell if Codea provided them, but that’s exactly (I think) what I’m providing too.

    Can’t use the console though. I couldn’t figure that one out. Would love help if anyone has ideas.

  • Posts: 1,060

    i have not reviewed your breakpoint stuff yet. one day, i shall. :smile:

  • Posts: 1,187

    @dave1707, @RonJeffries, about my breakpoints, I should be very clear: this is a bad solution.

    It's extremely kludgey; it's a huge cheat that runs around Codea's back and twists it into shapes it wasn't meant to go.

    It is no replacement for what people are calling for in this thread, which is a nice built-in, system-level set of basic debugging tools. I want to be really clear that I don't think my breakpoints make the need for those tools any smaller _at all.__ Out of desperation I made something that served my needs just barely, and I really think this is not the way things should be done.

    That said, a few explanations: there are two separate things happening here: the breakpoints, and the diagnostics. I invented the breakpoint system but the diagnostics are all native lua. Lua's debug.sethook system is primitive but it allows you to declare a function that gets run at either every line, every function call, every return from a function call, or some combination of those.

    So native lua, without any help from me, can provide line-by-line analysis of code. You can run it and then look at a big list of print statements, or however you stored the data you collected. The only thing it can't do is provide it live. That's what I did; the part I'm adding is the step-by-step.

    The way I enable step-by-step is essentially put an infinite loop after every line. I use the sethook command to activate an infinite loop that does only one thing: monitor keyboard input.

    This is a cheat. Codea is essentially broken at this point. You can’t interact with anything. Buttons don’t work, touches don’t get processed. You can’t use the console. It acts just like it would if it were actually stuck in a loop... because it is.

    The one thing it can do is respond to keyboard input. I searched and searched for a way to break out of an infinite loop and found nothing until I looked at the keyboard API. You can’t make anything happen asynchronously in Codea (even http calls don’t get processed in parallel) except for responses to keyboard events.

    So what’s happening in my step system is the sethook function processes a line, then my code hangs the whole system until the right keyboard keys are pressed, then sethook processes another line, and my code hangs the system again, and etc etc.

    Now as limited as this is, it can still be extremely useful. For one thing, it prints out the function name and line number at every step. So you can watch command flow as it happens. That right there helped me enormously.

    And with the function that gets passed to sethook you can perform any diagnostics you want, mostly. You can print out variables. You can do math. You can even run unit tests (in theory, I haven’t tried it). You can do anything you can do in a function. The one catch is scope. In my system you can only access global variables. You could write your own lua debugging code if you want, and include it in the callbacks my system does, because with lua’s built in tools it is possible to examine variables that are only in the scope of the current line, it’s just tricky and I don’t really know how to do it.

    But with those caveats, you can do at diagnostics you want, line by line, live. This again, though limited, was extremely helpful to me. Any variables I needed to monitor I just made global temporarily.

    So again my breakpoint system is no replacement for real debugging tools. It cannot (at least in any way I can figure out) let you interact with your program while you step through it. It can however expose control flow, which is extremely useful, and it can run any diagnostic function you write, live, line-by-line, which is also extremely useful—at least it was for me.

    And that said, it’s a big big big big +1 from me to the call for real, baked-in, not-cheating diagnostic tools.

  • dave1707dave1707 Mod
    Posts: 9,287

    @UberGoober After all that I still don’t know how to do anything. It’s like the keyboard does nothing except for the tab, if I had one and qq. What are the exact steps to dump a variable because everything I try does nothing. So what’s the step by step.

  • Posts: 1,060

    where's the version that uses hooks, i just found the one that hangs in draw.

  • edited June 2 Posts: 1,187

    @RonJeffries I assumed by hooks you meant the same thing lua does with the sethook command, but perhaps you don’t. Could you clarify?

    @dave1707 I’ll change it so it uses a letter when I have a moment. When you say “I can’t do anything,” that’s exactly right, you can’t do anything. You can watch the code progress line by line, which lets you snoop the flow of the code, and you can write a callback that does something every line, which will most likely be to print the value of some variables. That way you can see how values are changing and at what line they’re being changed.

    So if by “dump a variable” you mean print to console what its value is at every step, that’s trivial, you just pass in a function that prints that variable. Any function that you want to run at every line will run at every line.

    If that’s still unclear, maybe look at the Flappy program and tell me a value you’d like to see printed to screen and the line where you want the breakpoint to start and I’ll set it up for you. Or if you prefer you could write something of your own and tell me what you want to inspect and I’ll set it up.

  • Posts: 1,187

    @dave1707 @RonJeffries I’ve updated the demo now.

    The keys are now ‘t’ to step/resume and ‘q’ to turn breakpoints off altogether and go back to the running program.

    I’ve also updated the instructional text and the callback functions to better demonstrate and explain what good this dang old thing is.

Sign In or Register to comment.