Why is one tab not being imported as a dependency?

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?

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

@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.

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

@UberGoober - had you just installed/upgraded Codea or a beta. The first project run generally crashes so it could be related to that.

@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.

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.

@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.

@UberGoober Not the project, but Codea itself.

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

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!

@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.

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 …

@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.

code

Wow!!!

@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.

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.

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.

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