SECOND: dofile(filename) its LUA.. but not in Corona!!??

Hi Danny,

what was that to close the TOPIC… even before I could answer?

It seems you was not even reading my Suggestion.

YES… i know Apple do not allow to COMPILE while Runtime!!

The Suggestion is… (on that you could have answered, rather just closing the topic)

Corona could have a dofile() or something corona specific ( includecode(“code.lua”) )

and JUST in the moment we click BUILD

  • Corona just includes dynamically all that codes at the place where we say Includecode!!
    BEFORE its finally BUILDS the app!
  • That would result… apple/android get a full compiles code, where nothing is to compile
    while runtime!

Did I explained it better now?

That would be just a WIN WIN Situation. Apple gets what they like and we Devs also.

Whats your Position on that? (before closing that Topic again :slight_smile:

regards
chris
[import]uid: 4795 topic_id: 21024 reply_id: 321024[/import]

What is the practical difference between dofile() and require() ? [import]uid: 108660 topic_id: 21024 reply_id: 83017[/import]

Require () is working on a Modulare base.
You would have to define things before and than call functions in that Module like
ModuleName.functioname()

That works in several cases, but there are several things also quiet hard to realize.

Anyhow. LUA dofile() or PHP (require()) just loads the content of the loaded file at
the position in your code where you implement the command without any classifying
or modulating.

Apple do not allow to compile while runtime. So my suggestion is simple to generate
the full code (while all that pieces comes included) BEFORE Building the App.

For us Developers that would mean, we could create external pieces and include them
in as many scenes we like… and to change (like a css file) we just would have to change
one file instead (as in my case right now 25 Files :slight_smile:

Hope that could clear your question?

greets
chris
[import]uid: 4795 topic_id: 21024 reply_id: 83019[/import]

Can’t you just do this?

code.lua:

return function()  
 e = 2.71828183  
end  

doCompiledFile.lua

function doCompiledFile( filename )  
 return require( filename )()  
end  

main.lua

require "doCompliedFile"  
  
doCompiledFile( "code" )  
  
print( e )  

[import]uid: 12822 topic_id: 21024 reply_id: 83026[/import]

guruk: I generally agree with you that dofile is very useful. However, we need to be very careful here because we don’t want to get on Apple’s bad side. Since nobody outside Apple understands the review process, we believe perception is an important element. If Apple is reviewing a Corona app, we want them to automatically think the app satisfies their requirements. If Corona gets a bad reputation from our users doing things that Apple doesn’t like, all Corona users may be subjected to more scrutiny or might just be flat out rejected without any consideration (sort of like Flash and Java apps were). So we will not let that case happen.

As for require, it is easier for us to lock down than dofile since it already has a search path restriction built in.

But I do see very useful things for dofile. Save game files are a perfect example. You could write save game state to Lua code (e.g. tables) to local storage. Then to restore the game, you just use dofile to load up the data. Technically, since you generated the file yourself, you are not downloading and executing arbitrary/untrusted code. But somebody not paying attention to Apple’s rules could misuse this and start using dofile to execute arbitrary downloaded code for any purpose. If this happens too often, we may get a bad reputation.

So I think there are two things you can do. First, get everybody to file a bug report or feedback to Apple explaining what you want to do and how their current rules are negatively impacting innovation. Second, help raise awareness in the Corona community that both Apple’s rules need to be followed. If we feel confident that all our users understand the rules or Apple further relaxes restrictions, we may expose dofile and trust everybody won’t misuse it.

(As a stop gap for things like reading Lua for save game files, we are considering including LPeg which would allow you to use Leg to parse Lua code. This should allow for things like reading back in Lua tables without actually executing code.)

[import]uid: 7563 topic_id: 21024 reply_id: 83029[/import]

I am sure that the same logic would apply even for loadstring, right?

At first it was to keep up with Android that iOS features were not introduced, now it is for the sake of all the developers and Apple. Right!!

[import]uid: 3826 topic_id: 21024 reply_id: 83033[/import]

Hi there,

thanks all for your enthusiastic ideas.

I really appreciate…

Just keep in mind… don’t run over the goal.

In Programming there are always options to code from the back head through the eyes.
Also even if we work with modules, I do not see a change to define for example a
runtime listener in the main source and to remove it in the Module … its not just about to print a simple string.

AND Corona is about simplifying.
In that Case its really just about to have the option creating external files, with code pieces
and to “include” them like a CSS / JavaScript or PHP Code into the MainCode where 'include (“xxx”)
is defined.

Also the Argument about APPLE restrictions are not valid, should the Corona Simulator/Builder
just include that pieces in our main code, creating kind a temporary new full sourcecode, BEFORE RUnning or Compiling.

Therefore, there is no need for compiling while runtime (Apple restrictions)
And we would get a simple option to create kind a template code, that we just include wherever we need AND… if we need to change something (like in css) we just do it in one file and not in all places where we need it.

Thanks and greets Chris

[import]uid: 4795 topic_id: 21024 reply_id: 83105[/import]

Hi Guruk. I was the one who closed them as there were 3 topics (two identical topics by one user if im not mistaken) on the same thing.

Let’s keep discussion of this limited to this thread. Makes life a lot easier to track it and follow then.

I would second ewings advice [import]uid: 84637 topic_id: 21024 reply_id: 83108[/import]

Hi Danny,
still it looks I did not made clear whats about.

Also Ewing tried to explain how to do with Require()

The whole story is just about to simply include that external Script Pieces
BEFORE we click RUN or BUILD into ONE CODE. (like in css, js …)

Therefore we have ONE Code and no prob with Apple at all.

And it is not even about to change LUA itself or whatever.
Finally its a PRE-Compile Feature that simply would act like a Editor to
IMPROVE the workflow !! Till now my Editor (Coda) does not do that and
I don’t know a better Environment on Mac, that would do .

In that case… if Corona could do that… YES… I would say again …CORONA MAKES CODING EASIER :slight_smile:
You may just bring it on the table at your next Meeting. Thx.
As you see in several Post… the interest in such a feature is there.

And I do not think its a big deal to implement (better than 5 Daily Builds just fixing GameCenter Bugs) /twinkle/

Greets
Chris

[import]uid: 4795 topic_id: 21024 reply_id: 83109[/import]

So you want a #define like C?

In simple terms,

#define dp print(“Hello this is a debug print statement”)
… stuff
…more stuff
#dp
…more and more stuff

And the compiler switches the #dp for the ‘real’ code at compile time.

That costs down on the number of lines of code, but obviously if the define is a large chunk of code, it means that using the code several times is pretty wasteful of memory.
In those circumstances, surely a normal (global) function would be better?

This is syntactic sugar, in my opinion.

[import]uid: 108660 topic_id: 21024 reply_id: 83110[/import]

if I would be able to solve my problem with Modules I would do!

Right now I have 25 Scenes (each one .lua file) (working with Director)

IN the beginning several Runtime Listeners are called
(for example to check if Keys are pressed on Android and or on ios/android if goes to suspend)

I tried first to make that Listeners in my Main.lua…

BUT when for example the device went into suspend I could not clean the groups (that was opened in the individual scenes)… within that Main.lua
Also there had to be called several individual calls per scene, that I could not do within the Main.lua

Ok… than I had all that listener functions individual in the Scenes.
I tried to do it with Modules… but as the Listener Functions are called within the Scene I could
not remove it within the Module.

Simplest example

scene.lua
calls a removeall() function
where all groups come cleaned and listeners removed.

Should this removeall() function stay in a module, it will simple not work, as the groups and listeners have been defined in the scene itself.
chris
[import]uid: 4795 topic_id: 21024 reply_id: 83117[/import]

Your English is good (better than my understanding of your language), but It is sometimes difficult to know your exact meaning.

I think you believe that when you switch scenes with Director, you have to clean up all listeners from every module you use.

>>scene.lua
calls a removeall() function
where all groups come cleaned and listeners removed.

Should this removeall() function stay in a module, it will simple not work, as the groups and listeners have been defined in the scene itself.
<<

Not so.
You only need to clean up the listeners for the module which is ‘closing’

Listeners for objects which are in the display groups are handled by Director automatically.
If your module adds a runtime listener which is not valid for the ‘next’ scene, you should clean that before changing.

As an example, here is some code from my app, where I am about to leave a scene that listens for shake events. The next scene should not, so I kill the listener off before I switch.
When I return to this scene, it recreates the shakeListener as part of the setup.

[code]
– onKey is a listener for someone tapping the ‘key’ button
–it makes the entire screen change to a new module

local function onKey( event )
audio.play( tickSound)
Runtime:removeEventListener( “touch”, onGridTouch)
Runtime:removeEventListener( “tap”, onGridTouch )
Runtime:removeEventListener(“accelerometer”,shakeListener)
director:changeScene(“key”,“crossfade”)
end

[/code] [import]uid: 108660 topic_id: 21024 reply_id: 83124[/import]

Here’s some suggestions on items that I picked up on in you post…

What version of Director are you using? I use 1.4 so that’s how I will frame up this reply.

If you are having 25 scenes of different lua files I would want each one to have it’s own specific cleanup function, surely there are some different listeners, timers, event handlers, etc in each scene. (Remember you don’t need to clean out display objects explicitly - as long as you are removing the parent group all display objects below get wiped out as well)

In Director 1.4 it will automatically call a function name “clean” on the current scene when you switch scenes. --stay with me I know you are not talking about scene changes.

I suspect this is the same sort of activity you want to happen on your suspend event though?

What I would look into doing is just extend the Director code by adding a function called something like “SuspendMe” that calls the current scene’s “clean” method or any other method for that matter if you want it to do something different.

You could invoke it the same way you call any of your director:changeScene calls, so in main.lua you could handle whatever global event you wanted and call director:SuspendMe that ultimately calls your current scene’s whatever method you wire to.

Anytime I mention Director I like thank Ricardo Rauber for his great contribution, it has helped me tremendously.

Maybe that gives you another option if I’m understanding you correctly.
–Croisened

[import]uid: 48203 topic_id: 21024 reply_id: 83125[/import]

:slight_smile: now it comes a lot… i will have a look into all (by time)

@ jeff472 thanks… and yes… i do kind you do
before i leave the scene i remove all listeners.

and thats… I have in each scene a block of things like
(create listener, get result from listener, remove before scene close)

finally all that code look 99% same in each scene!

so I was just looking for a solution that I could define that block of code
outside of my actual scenes and just define it one time and than include (dofile() or however it will be called) to implement it in each scene. Finally even I would have to make a change to that blocks… i have to do it once, in the external file and it would be changed in all scenes.

@croisend… thanks have to look into it… also I feel it is not what I am looking for …

Anyhow… right now I play directly with some functions in the main.lua (while in use with director)… as i can access all functions within that main.lua directly like function name() in each of my scenes WITHOUT to do a precall like 'modulename.functionname() … i may have some solution in there…

will have to play around with it :slight_smile:

greets
chris
[import]uid: 4795 topic_id: 21024 reply_id: 83132[/import]

If your code is 99% the same in each scene, then you’re doing it wrong. Make the 99% part a module (include). But if you really want help with this, I suggest posting some code samples so we can actually see what it is you’re trying to do… I think we’re all kind of guessing at this point.

[import]uid: 19193 topic_id: 21024 reply_id: 83136[/import]