Re: eLua-dev Digest, Vol 35, Issue 27

classic Classic list List threaded Threaded
1 message Options
raman raman
Reply | Threaded
Open this post in threaded view
|

Re: eLua-dev Digest, Vol 35, Issue 27



On Thu, Jun 9, 2011 at 7:51 PM, <[hidden email]> wrote:
Send eLua-dev mailing list submissions to
       [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.berlios.de/mailman/listinfo/elua-dev
or, via email, send a message with subject or body 'help' to
       [hidden email]

You can reach the person managing the list at
       [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of eLua-dev digest..."


Today's Topics:

  1. Re: http://new.eluaproject.net/overview/status (James Snyder)
  2. Re: Sub-directory support for ROMFS (Dado Sutter)
  3. Re: Sub-directory support for ROMFS (Bogdan Marinescu)
  4. Re: Sub-directory support for ROMFS (Dado Sutter)


----------------------------------------------------------------------

Message: 1
Date: Thu, 9 Jun 2011 12:10:41 -0500
From: James Snyder <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] http://new.eluaproject.net/overview/status
Message-ID
: <[hidden email]>
Content-Type: text/plain;       charset=us-ascii

Yeah. I'm not sure I would add intermediate levels of status. There's no reason to make it more confusing :)

I also support using a less color-oriented scheme for status as well seeing as I'm also partly color-blind.

--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: <a href="tel:%28847%29%20448-0386" value="+18474480386">(847) 448-0386

On Jun 9, 2011, at 6:51, Martin Guy <[hidden email]> wrote:

>>>> On Tue, Jun 7, 2011 at 6:13 AM, Martin Guy <[hidden email]> wrote:
>>>>> What does it take for a newly supported feature to transition from an
>>>>> orange blob to a green tick?
>> I agree that the current scheme is pretty vague and we should refine it.
>> Maybe more "levels" for the status would help it too.
>
> Or less, seeing that orange and yellow mean the same thing (i.e. "is"
> instead of "isn't")
>
>   M.
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev


------------------------------

Message: 2
Date: Thu, 9 Jun 2011 14:40:52 -0300
From: Dado Sutter <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] Sub-directory support for ROMFS
Message-ID: <BANLkTimq06=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Jun 9, 2011 at 04:11, Bogdan Marinescu
<[hidden email]>wrote:

> Hi Raman,
>
> On Thu, Jun 9, 2011 at 9:59 AM, Raman Gopalan <[hidden email]>wrote:
>
>> Hello,
>>
>> I am a student. I have been working with Elua on LM3S8962.
>> I notice that the ROMFS is a flat file system. I would like to
>> implement a sub-directory feature for ROMFS. Is it viable ?
>> Is there a reason this feature doesn't already exist ?
>>
>> Please tell me if I am in the right direction.
>>
>
> Currently eLua doesn't have the concept of directories at all. For
> simplicity, it just assumes a filesystem with a single directory (the root
> directory).  That said:
>
> 1. adding directory support is not that difficult
> 2. in the particular case of ROMFS, "/" is an allowed character in a
> filename. For example, "dir/a.txt" is a valid filename. Obviously this isn't
> the same as having directories, but it might be enough for many practical
> cases. But you're going to have to modify mkfs.py (the ROMFS file system
> generator) to take advantage of this feature.
>

You might need to augment the maximum length allowed for a file name too,
which is currently 14, in src/fatfs/ff.h if I'm not wrong.

 Best,
> Bogdan
>

Best
Dado




>
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/elua-dev/attachments/20110609/a6fd1526/attachment-0001.html>

------------------------------

Message: 3
Date: Thu, 9 Jun 2011 20:43:01 +0300
From: Bogdan Marinescu <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] Sub-directory support for ROMFS
Message-ID: <BANLkTik7iUBW+8kPS=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Jun 9, 2011 at 8:40 PM, Dado Sutter <[hidden email]> wrote:

>
>
> On Thu, Jun 9, 2011 at 04:11, Bogdan Marinescu <[hidden email]
> > wrote:
>
>> Hi Raman,
>>
>> On Thu, Jun 9, 2011 at 9:59 AM, Raman Gopalan <[hidden email]>wrote:
>>
>>> Hello,
>>>
>>> I am a student. I have been working with Elua on LM3S8962.
>>> I notice that the ROMFS is a flat file system. I would like to
>>> implement a sub-directory feature for ROMFS. Is it viable ?
>>> Is there a reason this feature doesn't already exist ?
>>>
>>> Please tell me if I am in the right direction.
>>>
>>
>> Currently eLua doesn't have the concept of directories at all. For
>> simplicity, it just assumes a filesystem with a single directory (the root
>> directory).  That said:
>>
>> 1. adding directory support is not that difficult
>> 2. in the particular case of ROMFS, "/" is an allowed character in a
>> filename. For example, "dir/a.txt" is a valid filename. Obviously this isn't
>> the same as having directories, but it might be enough for many practical
>> cases. But you're going to have to modify mkfs.py (the ROMFS file system
>> generator) to take advantage of this feature.
>>
>
> You might need to augment the maximum length allowed for a file name too,
> which is currently 14, in src/fatfs/ff.h if I'm not wrong.
>

That's for FATFS only. The global limit is in inc/newliv/devman.h:

// GLOBAL maximum file length (on ALL supported filesystem)
#define DM_MAX_FNAME_LENGTH   30

Best,
Bogdan


>
>  Best,
>> Bogdan
>>
>
> Best
> Dado
>
>
>
>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/elua-dev/attachments/20110609/f04450bf/attachment-0001.html>

------------------------------

Message: 4
Date: Thu, 9 Jun 2011 14:50:52 -0300
From: Dado Sutter <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] Sub-directory support for ROMFS
Message-ID: <BANLkTi=b=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Jun 9, 2011 at 14:43, Bogdan Marinescu
<[hidden email]>wrote:

>
>
> On Thu, Jun 9, 2011 at 8:40 PM, Dado Sutter <[hidden email]> wrote:
>
>>
>>
>> On Thu, Jun 9, 2011 at 04:11, Bogdan Marinescu <
>> [hidden email]> wrote:
>>
>>> Hi Raman,
>>>
>>> On Thu, Jun 9, 2011 at 9:59 AM, Raman Gopalan <[hidden email]>wrote:
>>>
>>>> Hello,
>>>>
>>>> I am a student. I have been working with Elua on LM3S8962.
>>>> I notice that the ROMFS is a flat file system. I would like to
>>>> implement a sub-directory feature for ROMFS. Is it viable ?
>>>> Is there a reason this feature doesn't already exist ?
>>>>
>>>> Please tell me if I am in the right direction.
>>>>
>>>
>>> Currently eLua doesn't have the concept of directories at all. For
>>> simplicity, it just assumes a filesystem with a single directory (the root
>>> directory).  That said:
>>>
>>> 1. adding directory support is not that difficult
>>> 2. in the particular case of ROMFS, "/" is an allowed character in a
>>> filename. For example, "dir/a.txt" is a valid filename. Obviously this isn't
>>> the same as having directories, but it might be enough for many practical
>>> cases. But you're going to have to modify mkfs.py (the ROMFS file system
>>> generator) to take advantage of this feature.
>>>
>>
>> You might need to augment the maximum length allowed for a file name too,
>> which is currently 14, in src/fatfs/ff.h if I'm not wrong.
>>
>
> That's for FATFS only. The global limit is in inc/newliv/devman.h:
>
> // GLOBAL maximum file length (on ALL supported filesystem)
> #define DM_MAX_FNAME_LENGTH   30
>

We may need to update the doc at
http://www.eluaproject.net/en_arch_romfs.html, where the file name limit for
a ROMFS file is said to be 14.

Hello,

Thanks for the reply. Will check on the macro and tweak it.

Raman.

>
> Best,
> Bogdan
>

Best
Dado





>
>
>>
>>  Best,
>>> Bogdan
>>>
>>
>> Best
>> Dado
>>
>>
>>
>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/elua-dev/attachments/20110609/292098a6/attachment.html>

------------------------------

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


End of eLua-dev Digest, Vol 35, Issue 27
****************************************


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev