Coronium looks nice!
The current plan for luvit regarding callbacks is to support the old
behavior, but there is a new feature where you can block a coroutine by
passing in the thread in place of the callback.
fs.readFile("path/to/file", function (err, data) --[[ do something]]
end)
vs
local thread = coroutine.running()
local data = fs.readFile("path/to/file", thread)
This obviously require running in a coroutine so that the entire program
and event loop isn't blocked. It should come in real handy for cases where
you have nothing to do with a particular request while waiting for I/O.
On Tue, Dec 2, 2014 at 3:37 PM, develephant <[email protected]>
wrote:
> Thanks Tim,
>
> I'm torn on the callbacks, I've been using luvit for the last year and now
> I am quite used to it, but interested in new things as well.
>
> It's currently being beta tested by some developers, but I have created a
> game server/client for Corona SDK with luvit that getting some good
> response. It's at http://coronium.gs | docs <http://coronium.gs/server/>
>
> Thanks for your time, and great work.
>
> Cheers.
>
> On Tuesday, December 2, 2014 1:42:47 PM UTC-6, Tim Caswell wrote:
>>
>> Thanks! Ryan (rphillips) is the main person working on that layer
>> currently. I'm sure this feedback will help things move along. We're
>> working as fast as we can to port the virgo agent (http://virgoagent.com/)
>> from the old luvit to the new luvi-based luvit. Ideally it would require
>> minimal changes to virgo itself and there would be few breaking changes.
>>
>> With the new split between luv, luvi, and luvit, people who don't agree
>> with the opinions or APIs in luvit can still use the core technology and
>> build their own thing with minimal effort. This also means we can preserve
>> the old APIs in luvit without holding others back who may want to explore
>> other styles. (personally I'm really excited about moving away from
>> callbacks)
>>
>>
>> On Tue, Dec 2, 2014 at 1:23 PM, develephant <[email protected]>
>> wrote:
>>
>>> So, one:
>>>
>>> *process:on( "error", function( e )*
>>> * p( "Process Error", e )*
>>> *end )*
>>>
>>> the process global does not seem to be registering, I get "attempt to
>>> call method 'on' (a nil value)"
>>>
>>>
>>> *net.createServer()*
>>>
>>> Is now throwing "attempt to index local 'options' (a nil value)", I
>>> assume I am now required to pass a function.
>>>
>>>
>>> The following (incomplete for brevity) snippet:
>>>
>>>
>>>
>>>
>>>
>>> *function Server:listenCallback( e ) print( 'listening' )endfunction
>>> Server:onClient( client ) p( client )endfunction Server:start() self.server
>>> = net.createServer( utils.bind( self.onClient, self ) ) self.server:listen(
>>> 7173, utils.bind( self.listenCallback, self ) ) self.server:on("error",
>>> function( err ) assert( err ) end )end*
>>>
>>> The callback binding for for the "createServer" method is returning
>>> "nil" as the client. If I do this it works fine:
>>>
>>> *self.server = net.createServer( function( client ) *
>>> * p( client )*
>>> *end )*
>>>
>>> Same happens with:
>>>
>>> *client:on( "data", utils.bind( self.onData, self ) )*
>>>
>>> The data is "nil" it could be possible that something in the utils.bind
>>> is not passing the value, as I can do:
>>>
>>>
>>> *function Server:listenCallback( e ) print( 'listening' )end*
>>> *self.server:listen( 7173, utils.bind( self.listenCallback, self ) )*
>>>
>>> And I will get the 'listening' message printed.
>>>
>>> Again, all of these examples are out of context, but the codebase runs
>>> on pre-luvi luvit. I really like what you're doing with luvi by the way.
>>> Great idea.
>>>
>>> Best
>>>
>>> On Tuesday, December 2, 2014 12:57:23 PM UTC-6, Tim Caswell wrote:
>>>>
>>>> That is the goal, but the new luvit is not done. Tell us what's not
>>>> working and we can prioritize those features.
>>>>
>>>> On Tue, Dec 2, 2014 at 12:46 PM, develephant <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am using the new luvit with luvi build, and after moving over my
>>>>> code from my project, I am getting some errors. It works fine with the
>>>>> pre-luvi luvit, which is what is was developed on.
>>>>>
>>>>> Should pre-luvi luvit code work on the new build? Thanks in advance.
>>>>>
>>>>> Cheers.
>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "luvit" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "luvit" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "luvit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"luvit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
