headers
Bradley Smith | 1 Feb 01:16

Re: Premake vs. CMake

Brandon Van Every wrote:
>
> Usually when I see the "we prefer premake" sentiment, or some
> such for another build tool, it's a small project.

I'm one of those people who prefer premake. I'm project leader on 127K 
lines of C++ code, 312K with generated code. Whatever size project that is.

> I've been
> interested in what advantages these tools offer, whether for small
> projects, or otherwise.  I'm also interested in people's perceptions
> about the advantages, and how that squares with design, maintenance,
> and scale-up over the long haul.  For instance, many people are of the
> opinion that a mainstream programming language is beneficial to a
> build system.

I agree with the opinion that a mainstream language is beneficial to the 
build system (especially Lua). Lua has a great balance of power and 
simplicity, and is well documented and easy to learn.

> Have you seen that actually pay off for you in some
> tangible way?

Yes. We use Lua not only with premake, but also in custom build scripts 
(packaging for distribution, code generation, license key creation) and 
in embedded testing and scripting of the application.

> Or was it about comfort level, feeling that you didn't
> have to learn something new, and it didn't turn out to matter in
> practice?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yuri Takhteyev | 1 Feb 01:42
Picon
Gravatar

Re: [OT] Re: South American Software Development

As Luiz Henrique mentioned (and as I said in my introduction last
year), I do research in this area, writing a dissertation about
software developers in Rio, which I hope will do a good job of
representing their experiences and perspectives.  (Note the
plural on "perspectives" - there are more then one.)  I also
happen to be the author of the study mentioned in the third
quote, though the conclusion about "rigid national boundaries" is
Michael Swaine's, not mine.

I am not sure if this is the right forum to discuss those issues
(and one should be careful when using Lua to take the pulse of
software development in South America), but when my dissertation
is ready (sometime in the next 12 months), I will gladly share it
with anyone who wants to know more about software development in
Rio de Janeiro.  (You can also reply to me off the list and I'll
put you on the list of people to email the link to when its
ready.)  Also, if anyone is interested in looking at
not-quite-final drafts of chapters, email me.  Finally, if anyone
has any questions, email me off the list and I will try to answer
them as best as I can.  (If some questions get repeated, I'll
might an "FAQ" to the list later.)  Those who will be attending
the Lua Workshop can look for me there to ask questions in
person.  (And if anyone in SF or Berkeley who wants to meet and
talk Lua, holler.)

Now, let me make a few brief caveats about the first two quotes
that John mentioned and a longer one about the third, since my
study is implicated in it.

>  "Nearly one professional developer in ten worldwide is working and
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Meijer | 1 Feb 01:55
Picon

Re: Memory leak?

Btw... I do hope I haven't offended anyone with this... I know I can
be a bit blunt sometimes, but I never mean any disrespect.

I felt I needed to get that off my chest. FWIW

Sincerely,
Mark

On 31/01/2008, Mark Meijer <meijer78 <at> gmail.com> wrote:
> Come to think of it, it should probably be a function called on
> individual tables, rather than one function which does all tables,
> which might not be practical.
>
> I don't know jack all about Lua internals, but I've taken a look at
> ltable.c and I found the resize function, as well as a couple of
> places that trigger it, directly or indirectly (in table.c but also
> for example in lvm.c at the opcode that sets table entries). But as I
> don't know half of what's going on in there, I wouldn't feel
> comfortable exposing anything like that to Lua or the C API, even if I
> did know how to do that neatly.
>
>
>
> On 30/01/2008, Mark Meijer <meijer78 <at> gmail.com> wrote:
> > On 30/01/2008, alex.mania <at> iinet.net.au <alex.mania <at> iinet.net.au> wrote:
> > > I'm guessing you saw in the reply that the GC can collect the keys =). So the
> > > loss is only minor - it's only the 28 (or 32, depending on kludge factor) bytes
> > > for a Node. The key can still be collected, just not the node.
> >
> > Yeah :) Thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
alex.mania@iinet.net.au | 1 Feb 02:17
Picon
Picon
Favicon

Re: patch: C-style string lexing

On Fri Feb  1  4:11 , Mike Pall <mikelu-0801 <at> mike.de> sent:

>[Or let a "sufficiently smart" JIT compiler do this for you.
>Nope, LuaJIT 1.x won't do this for you -- it doesn't pay off
>because it's too rare. But LuaJIT 2.x might do this as a
>side-effect.]
>
>--Mike

I have so many questions about the 2.x's... although mostly, is there any vague
form of eta on them? (The other two main ones are is there a list anywhere of
improvements, and whether it'll still be easily modifiable - we have a need for
non-C call convention for example).

- Alex
Permalink | Reply | 0 comments |
headers
Leo M. Cabrera | 1 Feb 02:17
Picon

Re: [OT] Re: South American Software Development

You're counting South American developers? Me! Me! I'm Uruguayan. ;)

Yuri Takhteyev wrote:
> As Luiz Henrique mentioned (and as I said in my introduction last
> year), I do research in this area, writing a dissertation about
> software developers in Rio, which I hope will do a good job of
> representing their experiences and perspectives.  (Note the
> plural on "perspectives" - there are more then one.)  I also
> happen to be the author of the study mentioned in the third
> quote, though the conclusion about "rigid national boundaries" is
> Michael Swaine's, not mine.
>
> I am not sure if this is the right forum to discuss those issues
> (and one should be careful when using Lua to take the pulse of
> software development in South America), but when my dissertation
> is ready (sometime in the next 12 months), I will gladly share it
> with anyone who wants to know more about software development in
> Rio de Janeiro.  (You can also reply to me off the list and I'll
> put you on the list of people to email the link to when its
> ready.)  Also, if anyone is interested in looking at
> not-quite-final drafts of chapters, email me.  Finally, if anyone
> has any questions, email me off the list and I will try to answer
> them as best as I can.  (If some questions get repeated, I'll
> might an "FAQ" to the list later.)  Those who will be attending
> the Lua Workshop can look for me there to ask questions in
> person.  (And if anyone in SF or Berkeley who wants to meet and
> talk Lua, holler.)
>
> Now, let me make a few brief caveats about the first two quotes
> that John mentioned and a longer one about the third, since my
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Hamburg | 1 Feb 02:44
Picon
Favicon

Re: patch: C-style string lexing

Actually, can you do the folding of the string concatenation in the lexer?
Instead of eliminating "< whitespace >" one would patch the lexer to
eliminate "< optional whitespace >..< optional whitespace >".

Mark
Permalink | Reply | 9 comments |
headers
Brandon Van Every | 1 Feb 03:31
Picon

Re: Premake vs. CMake

On Jan 31, 2008 7:16 PM, Bradley Smith <gmane <at> baysmith.com> wrote:
> Brandon Van Every wrote:
> >
> > Usually when I see the "we prefer premake" sentiment, or some
> > such for another build tool, it's a small project.
>
> I'm one of those people who prefer premake. I'm project leader on 127K
> lines of C++ code, 312K with generated code. Whatever size project that is.

I'd call it medium sized.

> Learning something new isn't about discomfort. It is about cost versus
> benefit. If the new knowledge can be used in many ways, the benefit
> outweighs the cost. On the other hand, if the new knowledge can only be
> used to build the project, the cost may outweigh the benefit.

I think, though, there are times when people act like they're going to
have to learn tons of stuff, when in practice they don't have to.  I'm
not sure how true that is of CMake at present.

Cheers,
Brandon Van Every
Permalink | Reply | 0 comments |
headers
Brandon Van Every | 1 Feb 03:38
Picon

Re: Premake vs. CMake

On Jan 31, 2008 6:34 PM, RJP Computing <rjpcomputing <at> gmail.com> wrote:
> Well if the tool makes you change it setup files for every file that
> is added to a project, that in my opinion sucks.

So I take it you would prefer the build tool automagically infer what
you want, like building with every single .c .h file in a directory?
That doesn't work if you have multiple libraries and apps in a single
directory.  You're going to have to specify that these are separate
apps and libs somewhere.

So then, perhaps you think you should be able to specify them in your
favorite IDE.  Well that's not going to work cross-platform and
cross-IDE.  Not unless you develop some really funky mechanism for
translating from your native IDE's build files to the cross-platform
CMake file.  CMake --> native IDE is a heckuva lot easier to implement
than native IDE --> CMake.

> I did try CMake, at the
> beginning, when I investigated using such a tool and was not happy with it's
> complexity and how you had to have files in sub-directories that called out
> what files to build. I am not sure how accurate this is today, I tried it
> 2.5 years ago.

CMake started life as a directory oriented tool.  Now it's a target
oriented tool.

Cheers,
Brandon Van Every
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Tetz | 1 Feb 03:39
Picon

Re: patch: C-style string lexing

On Jan 31, 2008 5:44 PM, Mark Hamburg <mhamburg <at> adobe.com> wrote:
> Actually, can you do the folding of the string concatenation in the lexer?
> Instead of eliminating "< whitespace >" one would patch the lexer to
> eliminate "< optional whitespace >..< optional whitespace >".

>From my limited understanding of it, I think it would just get too
messy. You'd have to look ahead two tokens: gotta see if the following
token is a '..' (and not '...' or '.314'), then hold onto that while
you check beyond that for a string delimiter. It would be a major hack
(AFAIK), whereas just skipping space between strings falls out of the
existing code with no effort.
Permalink | Reply | 0 comments |
headers
Brandon Van Every | 1 Feb 04:14
Picon

Re: Are parenthesis-free calls a Good? (was Re: patch: C-style string lexing)

On Jan 31, 2008 5:36 PM, Ben <thebassplayer <at> gmail.com> wrote:
>
> In Lua, function calls with parentheses are just as readily available
> as those without parentheses.  It's quite easy to encourage the
> convention of always using parentheses in function calls.  Companies
> and projects make standards on indentation size and brace placement in
> source code all the time; this doesn't seem any different.

So how do you enforce that?  And what good does it do you, if the
standards are different across companies and you're using 3rd party
Lua code?  That's the situation CMake developers would inevitably be
in.

Cheers,
Brandon Van Every
Permalink | Reply | 6 comments |

Gmane