SD Card appears shows 0 files after running some files
Locked
 
|
Ed Hatfield |
SD Card appears shows 0 files after running some files
|
I've been trying to track down a strange problem with no success. When running some applications from the SD card on the LM3S board, the /mmc directory sometimes reports 0 files.
An example using some of the LM3S games...After running "/mmc/tetrives.lua", "ls" shows the files on the SD card. After running "/mmc/pong.lua", "ls" shows 0 files on the SD card.
Possibly related, it seems that running a lua script from the SD card that attempts to open another file (dofile, io.open) on the SD card will report that the file is not found. The romfs doesn't seem to have this problem.
Any thoughts? -Ed _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Thu, Jun 23, 2011 at 8:53 AM, Ed Hatfield <[hidden email]> wrote:
I've been trying to track down a strange problem with no success. When running some applications from the SD card on the LM3S board, the /mmc directory sometimes reports 0 files. The SD/MMC FS is known to cause problems on certain platforms/with certain cards which makes this issue quite tricky to fix. I'm afraid I don't have a good answer for you. If possible, try using another card. Is this doesn't work either we'll have to do some debugging.
Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Is the procedure you describe able to consistently give you this behavior? Also could you provide any info about the brand/capacity/formatting of the card? -- James Snyder Biomedical Engineering Northwestern University ph: (847) 448-0386
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Ed Hatfield |
Re: SD Card appears shows 0 files after running some files
|
|
Yes, it's happens every time. It's an Taiwanese SD-C02G unbranded 2GB Micro SD. Used default formatting first, then reformatted under Windows using the default formatting FAT, 32KB allocation.
-Ed
On Thu, Jun 23, 2011 at 12:33 PM, James Snyder <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Ed Hatfield |
Re: SD Card appears shows 0 files after running some files
|
|
In reply to this post by jbsnyder
Digging into the problem a bit more, I tried both SanDisk 4GB & PNY 4GB micro SD cards. All have the same problem. So that's (1) 2GB/FAT16 and (2) 4GB/FAT32 cards.
Here's the text from my terminal session...
eLua# lua /mmc/pong.lua Press CTRL+Z to exit Lua eLua# lua /mmc/pong.lua Press CTRL+Z to exit Lua lua: cannot open /mmc/pong.lua: No such file or directory
eLua# On Thu, Jun 23, 2011 at 12:33 PM, James Snyder <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Jun 23, 2011 at 9:14 PM, Ed Hatfield <[hidden email]> wrote:
Digging into the problem a bit more, I tried both SanDisk 4GB & PNY 4GB micro SD cards. All have the same problem. So that's (1) 2GB/FAT16 and (2) 4GB/FAT32 cards. Hmmm. Does it happen when you run something else than pong.lua ? Best,
Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: SD Card appears shows 0 files after running some files
|
|
On Thu, Jun 23, 2011 at 14:17, Bogdan Marinescu <[hidden email]> wrote:
It shouldn't make any difference, because a new "eLua state" is started when going back to the shell no ?
Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Thu, Jun 23, 2011 at 9:23 PM, Dado Sutter <[hidden email]> wrote:
It's not that. I'm thinking that since 'pong.lua' uses the display it might reconfigure some GPIO pins that are connect to the SD/MMC slot or do some other operation that I can't imagine right now :)
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Dado Sutter |
Re: SD Card appears shows 0 files after running some files
|
|
On Thu, Jun 23, 2011 at 14:25, Bogdan Marinescu <[hidden email]> wrote: Hi, Right. The onboard OLED display depends on SPI, as well as the SD/MMC File System does. Pong itself (the Lua code) doesn't do any special hw configurations, other than using the regular eLua modules. These of course may be causing the issue. I'm away from the Lab (for yet ~3 more weeks) but I'll see if anyone can reproduce it there too, which actually doesn't seem necessary based on the reports, that clearly show the problem. It is just that this sound strange to me, as we've been using the lm3s.disp module and MMC on LM3S8962 and LM3S6965 for quite some time now and no problem has been noticed before. Of course this doesn't hide the fact that no extensive tests were done in any of these platforms. This is one of the many areas we need to improve and, like for all the others, we need help and collaboration to deal with all the issues. Tks for the report Ed !
Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Ed Hatfield |
Re: SD Card appears shows 0 files after running some files
|
|
In reply to this post by BogdanM
Yes, it happens with other files too. I think it _might_ be just when running files that use the display.
-Ed On Thu, Jun 23, 2011 at 2:17 PM, Bogdan Marinescu <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Jun 23, 2011 at 9:37 PM, Ed Hatfield <[hidden email]> wrote: Yes, it happens with other files too. I think it _might_ be just when running files that use the display. Thanks. A quick check of the code confirms that while the SPI card is initialized in SSI_FRF_MOTO_MODE_0 mode the display initialization function (RIT128x96x4Enable) changes the SSI mode to SSI_FRF_MOTO_MODE_2 (and also the SPI speed) which is most likely causing this issue. This kind of stuff happens from time to time when an interface is shared between more than one device. We could have the 'disp' module perform a 'restore SPI state' operation on close, but this would still mean that any program that uses the display won't be able to access the SD/MMC card. The best fix would be a hardware modification, obviously not applicable here. Apart from that, we could implement a "SPI dispatcher" in software that receives SPI requests (read/write) from different eLua modules (SD/MMC and 'disp' in this case) and knows how to setup the SPI interface (mode+speed) for each module in part before executing the request. If all the SPI-related code in the system uses this dispatcher the problem would be fixed. Kind of cumbersome though, but we might have to do it.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Jun 23, 2011 at 1:55 PM, Bogdan Marinescu
<[hidden email]> wrote: > > > On Thu, Jun 23, 2011 at 9:37 PM, Ed Hatfield <[hidden email]> wrote: >> >> Yes, it happens with other files too. I think it _might_ be just when >> running files that use the display. >> -Ed > > Thanks. A quick check of the code confirms that while the SPI card is > initialized in SSI_FRF_MOTO_MODE_0 mode the display initialization function > (RIT128x96x4Enable) changes the SSI mode to SSI_FRF_MOTO_MODE_2 (and also > the SPI speed) which is most likely causing this issue. This kind of stuff > happens from time to time when an interface is shared between more than one > device. We could have the 'disp' module perform a 'restore SPI state' > operation on close, but this would still mean that any program that uses the > display won't be able to access the SD/MMC card. The best fix would be a > hardware modification, obviously not applicable here. Apart from that, we > could implement a "SPI dispatcher" in software that receives SPI requests > (read/write) from different eLua modules (SD/MMC and 'disp' in this case) > and knows how to setup the SPI interface (mode+speed) for each module in > part before executing the request. If all the SPI-related code in the system > uses this dispatcher the problem would be fixed. Kind of cumbersome though, > but we might have to do it. As a workaround for this particular condition, we could have our mmcfs layer do one of the following: 1) attempt to reconfigure its communication with the card on failure (I think we want to do this anyways to handle some other situations, however it will usurp the display config and that might stop working if it doesn't have the same config) 2) on startup mmcfs will try to get the highest data rate it can with the card, so make note of this during config in global state. every time an operation is subsequently performed read the current configuration (in case it has changed outside), change it back to the mmcfs config, run the operation, then revert the config to what was stored at the start. For this I think the SPI modules might have to add some methods in order to be able to push and pop the configuration like that. 3) keep track of what was configured at startup, revert to this every time mmcfs performs an operation, don't worry about existing state and expect that anyone else using spi will have to do the same. No. 3 could pretty easily be done now. Either 2 or 3 could be combined with No. 1. Another approach which would actually change the API and would partially combine with one of the above would be to have spi.setup not actually perform configuration, but return a userdata or token that would be passed to spi.write or spi.readwrite so that the configuration would be available every time a read or write is performed? > Best, > Bogdan > >> >> >> On Thu, Jun 23, 2011 at 2:17 PM, Bogdan Marinescu >> <[hidden email]> wrote: >>> >>> On Thu, Jun 23, 2011 at 9:14 PM, Ed Hatfield <[hidden email]> wrote: >>>> >>>> Digging into the problem a bit more, I tried both SanDisk 4GB & PNY 4GB >>>> micro SD cards. All have the same problem. So that's (1) 2GB/FAT16 and (2) >>>> 4GB/FAT32 cards. >>>> Here's the text from my terminal session... >>>> eLua# lua /mmc/pong.lua >>>> Press CTRL+Z to exit Lua >>>> eLua# lua /mmc/pong.lua >>>> Press CTRL+Z to exit Lua >>>> lua: cannot open /mmc/pong.lua: No such file or directory >>>> eLua# >>> >>> Hmmm. Does it happen when you run something else than pong.lua ? >>> Best, >>> Bogdan >>> >>>> >>>> -Ed >>>> >>>> >>>> On Thu, Jun 23, 2011 at 12:33 PM, James Snyder <[hidden email]> >>>> wrote: >>>>> >>>>> Is the procedure you describe able to consistently give you this >>>>> behavior? >>>>> Also could you provide any info about the brand/capacity/formatting of >>>>> the card? >>>>> >>>>> -- >>>>> James Snyder >>>>> Biomedical Engineering >>>>> Northwestern University >>>>> http://fanplastic.org/key.txt >>>>> ph: (847) 448-0386 >>>>> On Jun 23, 2011, at 4:00, Bogdan Marinescu <[hidden email]> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Thu, Jun 23, 2011 at 8:53 AM, Ed Hatfield <[hidden email]> wrote: >>>>>> >>>>>> I've been trying to track down a strange problem with no success. >>>>>> When running some applications from the SD card on the LM3S board, the /mmc >>>>>> directory sometimes reports 0 files. >>>>>> An example using some of the LM3S games...After running >>>>>> "/mmc/tetrives.lua", "ls" shows the files on the SD card. After running >>>>>> "/mmc/pong.lua", "ls" shows 0 files on the SD card. >>>>>> Possibly related, it seems that running a lua script from the SD card >>>>>> that attempts to open another file (dofile, io.open) on the SD card will >>>>>> report that the file is not found. The romfs doesn't seem to have this >>>>>> problem. >>>>>> Any thoughts? >>>>> >>>>> The SD/MMC FS is known to cause problems on certain platforms/with >>>>> certain cards which makes this issue quite tricky to fix. I'm afraid I don't >>>>> have a good answer for you. If possible, try using another card. Is this >>>>> doesn't work either we'll have to do some debugging. >>>>> Best, >>>>> Bogdan >>>>> >>>>> _______________________________________________ >>>>> eLua-dev mailing list >>>>> [hidden email] >>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>> >>>>> _______________________________________________ >>>>> eLua-dev mailing list >>>>> [hidden email] >>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> eLua-dev mailing list >>>> [hidden email] >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>> >>> >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Jun 23, 2011 at 10:13 PM, James Snyder <[hidden email]> wrote: On Thu, Jun 23, 2011 at 1:55 PM, Bogdan Marinescu This makes the SD/MMC the undisputed master of the SPI interface :) which would be a bad idea for applications that need to use both the SD/MMC card and the display (or other SPI peripherals, if applicable). This is probably not desired most of the time.
Sure, this could work. It will be slow as hell but that's the price one has to pay for sharing one's hardware :)
I blieve that No 2 and 3 above are still better handled by a special module (the one I called "SPI dispatcher" in my previous e-mail). With a dispatcher you don't need to worry about what other modules would do, you just put your life in the hands of the dispatcher (and you know it does its job well). In this scenario, all that has to be done is make sure that all modules use the dispatcher. We can do this easily by making the platform interface itself reffer to the dispatcher. The modules that insist to access the SPI with direct I/O operations are on their own :)
Another approach which would actually change the API and would Absolutely, this should work. Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Ed Hatfield |
Re: SD Card appears shows 0 files after running some files
|
|
In reply to this post by BogdanM
Thanks for you help in tracking this down. I'll make some changes to verify this is the problem and I'll report back.
-Ed On Thu, Jun 23, 2011 at 2:55 PM, Bogdan Marinescu <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Ed Hatfield |
Re: SD Card appears shows 0 files after running some files
|
|
A quick hack to elua_mmc.c confirms that it was exactly the SPI issue mentioned.
I just simply called platform_spi_setup again in the SELECT function and the previous failures disappeared. (It's not the right fix, I know. But it it does verify the source of the problem.) Thanks again for your help.
The change... void SELECT (void) { //xxx - EJH - Hack to re-configure the SPI for MMC in case someone else has been using it platform_spi_setup( MMCFS_SPI_NUM, PLATFORM_SPI_MASTER, 400000, 0, 0, 8 ); platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ), PLATFORM_IO_PIN_CLEAR ); }
-EdOn Thu, Jun 23, 2011 at 3:52 PM, Ed Hatfield <[hidden email]> wrote: Thanks for you help in tracking this down. I'll make some changes to verify this is the problem and I'll report back. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Jun 24, 2011 at 12:05 AM, Ed Hatfield <[hidden email]> wrote:
A quick hack to elua_mmc.c confirms that it was exactly the SPI issue mentioned. Thank you for raising this issue and for your help debugging it. Now we only have to implement the right fix ... :) Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Jun 23, 2011 at 4:20 PM, Bogdan Marinescu
<[hidden email]> wrote: > On Fri, Jun 24, 2011 at 12:05 AM, Ed Hatfield <[hidden email]> wrote: >> >> A quick hack to elua_mmc.c confirms that it was exactly the SPI issue >> mentioned. >> I just simply called platform_spi_setup again in the SELECT function and >> the previous failures disappeared. (It's not the right fix, I know. But it >> it does verify the source of the problem.) Thanks again for your help. Ditto :-) > > Thank you for raising this issue and for your help debugging it. Now we only > have to implement the right fix ... :) Yep. Do you have a suggestion or proposal for the dispatcher? I actually like the userdata approach a fair amount. One approach that would allow us to avoid changing the API as much would be the following: Have the setup function do the configuration each time, but also return a token (instead of, or in addition to the clock?). I suppose we could cheat a little here and return a blob with metamethods to give the user the clock actually acquired but I don't think I would like that unless it's a named method for providing the clock acquired. Then have write/readwrite take either id or this token as a first parameter. This could take the place of using an id since the userdata could capture that from setup. This is a model that could, if needed be replicated to other places in the API where passing the token means: "use this id, with the setup I selected then" If the user passes an id number instead of the configuration token the command would be run using whatever configuration was last applied. I'd have to think more about what to do for the C side of the API, since technically that wouldn't even have to change to make this possible (just implement it in the Lua interface/module), but it could be integrated into how the C API works where the setup function could return or modify a structure passed to it. Do you have a proposal for the dispatcher (or is the above similar to that concept)? I'm not sure I understand what the suggestion would be for how it would keep track of who needed what configuration. Presumably you could have the granularity be on the level of the calling module so that it would essentially store named configurations for different source modules, or the dispatcher could hand out structures, tokens or ids that need to be handed to it each time so it knows which config to use? In the mean time, I wonder if there's a simpler fix without too many side effects? mmcfs's startup and running process is totally opaque to the user, but is constrained by the platform API in terms of what it can do to restore SPI functionality when it finishes. We could add some global state for the disp module and have it play nicely (pushing and popping configuration) each time it uses the bus. Since it's platform specific there's not a problem with it reading from registers or using LM3S' API to check on state. I think it is clear though that a better approach should be planned for future usage since mmcfs has no clean way of reasserting its control without overwriting other settings. > Best, > Bogdan > >> >> The change... >> >> void SELECT (void) >> { >> //xxx - EJH - Hack to re-configure the SPI for MMC in case someone >> else has been using it >> platform_spi_setup( MMCFS_SPI_NUM, PLATFORM_SPI_MASTER, 400000, 0, 0, >> 8 ); >> >> platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ), >> PLATFORM_IO_PIN_CLEAR ); >> >> } >> >> -Ed >> >> On Thu, Jun 23, 2011 at 3:52 PM, Ed Hatfield <[hidden email]> wrote: >>> >>> Thanks for you help in tracking this down. I'll make some changes to >>> verify this is the problem and I'll report back. >>> -Ed >>> >>> >>> On Thu, Jun 23, 2011 at 2:55 PM, Bogdan Marinescu >>> <[hidden email]> wrote: >>>> >>>> >>>> On Thu, Jun 23, 2011 at 9:37 PM, Ed Hatfield <[hidden email]> wrote: >>>>> >>>>> Yes, it happens with other files too. I think it _might_ be just when >>>>> running files that use the display. >>>>> -Ed >>>> >>>> Thanks. A quick check of the code confirms that while the SPI card is >>>> initialized in SSI_FRF_MOTO_MODE_0 mode the display initialization function >>>> (RIT128x96x4Enable) changes the SSI mode to SSI_FRF_MOTO_MODE_2 (and also >>>> the SPI speed) which is most likely causing this issue. This kind of stuff >>>> happens from time to time when an interface is shared between more than one >>>> device. We could have the 'disp' module perform a 'restore SPI state' >>>> operation on close, but this would still mean that any program that uses the >>>> display won't be able to access the SD/MMC card. The best fix would be a >>>> hardware modification, obviously not applicable here. Apart from that, we >>>> could implement a "SPI dispatcher" in software that receives SPI requests >>>> (read/write) from different eLua modules (SD/MMC and 'disp' in this case) >>>> and knows how to setup the SPI interface (mode+speed) for each module in >>>> part before executing the request. If all the SPI-related code in the system >>>> uses this dispatcher the problem would be fixed. Kind of cumbersome though, >>>> but we might have to do it. >>>> Best, >>>> Bogdan >>>> >>>>> >>>>> >>>>> On Thu, Jun 23, 2011 at 2:17 PM, Bogdan Marinescu >>>>> <[hidden email]> wrote: >>>>>> >>>>>> On Thu, Jun 23, 2011 at 9:14 PM, Ed Hatfield <[hidden email]> >>>>>> wrote: >>>>>>> >>>>>>> Digging into the problem a bit more, I tried both SanDisk 4GB & PNY >>>>>>> 4GB micro SD cards. All have the same problem. So that's (1) 2GB/FAT16 and >>>>>>> (2) 4GB/FAT32 cards. >>>>>>> Here's the text from my terminal session... >>>>>>> eLua# lua /mmc/pong.lua >>>>>>> Press CTRL+Z to exit Lua >>>>>>> eLua# lua /mmc/pong.lua >>>>>>> Press CTRL+Z to exit Lua >>>>>>> lua: cannot open /mmc/pong.lua: No such file or directory >>>>>>> eLua# >>>>>> >>>>>> Hmmm. Does it happen when you run something else than pong.lua ? >>>>>> Best, >>>>>> Bogdan >>>>>> >>>>>>> >>>>>>> -Ed >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 23, 2011 at 12:33 PM, James Snyder >>>>>>> <[hidden email]> wrote: >>>>>>>> >>>>>>>> Is the procedure you describe able to consistently give you this >>>>>>>> behavior? >>>>>>>> Also could you provide any info about the brand/capacity/formatting >>>>>>>> of the card? >>>>>>>> >>>>>>>> -- >>>>>>>> James Snyder >>>>>>>> Biomedical Engineering >>>>>>>> Northwestern University >>>>>>>> http://fanplastic.org/key.txt >>>>>>>> ph: (847) 448-0386 >>>>>>>> On Jun 23, 2011, at 4:00, Bogdan Marinescu >>>>>>>> <[hidden email]> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Thu, Jun 23, 2011 at 8:53 AM, Ed Hatfield <[hidden email]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I've been trying to track down a strange problem with no success. >>>>>>>>> When running some applications from the SD card on the LM3S board, the /mmc >>>>>>>>> directory sometimes reports 0 files. >>>>>>>>> An example using some of the LM3S games...After running >>>>>>>>> "/mmc/tetrives.lua", "ls" shows the files on the SD card. After running >>>>>>>>> "/mmc/pong.lua", "ls" shows 0 files on the SD card. >>>>>>>>> Possibly related, it seems that running a lua script from the SD >>>>>>>>> card that attempts to open another file (dofile, io.open) on the SD card >>>>>>>>> will report that the file is not found. The romfs doesn't seem to have this >>>>>>>>> problem. >>>>>>>>> Any thoughts? >>>>>>>> >>>>>>>> The SD/MMC FS is known to cause problems on certain platforms/with >>>>>>>> certain cards which makes this issue quite tricky to fix. I'm afraid I don't >>>>>>>> have a good answer for you. If possible, try using another card. Is this >>>>>>>> doesn't work either we'll have to do some debugging. >>>>>>>> Best, >>>>>>>> Bogdan >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> eLua-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> eLua-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> eLua-dev mailing list >>>>>>> [hidden email] >>>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> eLua-dev mailing list >>>>>> [hidden email] >>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> eLua-dev mailing list >>>>> [hidden email] >>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> eLua-dev mailing list >>>> [hidden email] >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>> >> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |