On Wed, 10 Mar 2004 20:49:15 +0100, Julio Jiménez wrote:

> When i try to create a new project, i get a messagedialog with: Unable to load project definition for project. :(

I think you can just ignore that (it's gone on the delopement version)

> 
> then i can write the specs for the project and compile and make.... but can't save the project itself... so i have to create the project again when i run leds.... :(

I thought that was fixed :(
check if you have the directories:
.leds
.leds_data
.leds_data/projects
on your user home directory.

I think the last published version already accepts
the 'home' and 'data' parameters:
leds --home anyDirectory --data anyDirectory

> Thanks for your great work.

:)

Ant

Ant wrote:
> On Wed, 10 Mar 2004 20:49:15 +0100, Julio Jiménez wrote:
> 
> 
>>When i try to create a new project, i get a messagedialog with: Unable to load project definition for project. :(
> 
> 
> I think you can just ignore that (it's gone on the delopement version)
> 
> 
>>then i can write the specs for the project and compile and make.... but can't save the project itself... so i have to create the project again when i run leds.... :(
> 
> 
> I thought that was fixed :(
> check if you have the directories:
> .leds
> .leds_data
> .leds_data/projects

no .leds_data/projects directory....
mkdir and saving projects.... :)


> on your user home directory.
> 
> I think the last published version already accepts
> the 'home' and 'data' parameters:
> leds --home anyDirectory --data anyDirectory
> 
> 
>>Thanks for your great work.
> 
> 
> :)
> 
> Ant
> 

imr1984 wrote:
> the other day i was studying assembly programming, and it struck me - why does D
> need semicolons after statements at all? they seem like a waste of time.
> 
> I think statements should be seperated by new lines OR semicolons, so that
> existing D code will still work.
> 
> Ive been programming C style languages for years now and i still often forget a
> semicolon - so i think this would be a big time saver, as well as making the
> code more readable

Over the past five years I've worked quite extensively in C, C++ and JavaScript. (and Smalltalk and APL, but let's not go there...)  I'm in the process of adding Python and Java to the mix. Hopefully D will be part of that mix.

Except for Python, all of these language support a "C like syntax". Semi-colons as line terminators are optional in both JavaScript and Python.

<rant>
IMHO *optional* line terminators are just about the daftist feature I can think of. (Right after operator overloading in C++, one of my coworkers just found a byte buffer class in the depths of our code that *knows* how to cast itself into a BSTR, try figuring that one out...)

This *feature* has caused more trouble than it's worth. Even worse, because it's optional, it becomes hard to enforce good coding practices.
</rant>

Since I did actually take a course in compiler construction [or at least my transcript says I did, it's a little fuzzy] I can also testify that a line terminator makes the grammer easier to parse. [I noticed in the Rhino implementation of JavaScript that one of the parsing steps is to figure out where the semi-colons should go... that was when I started adding semi-colons to some of the sloppier files in my project...]

-- 
Alex

why can't the compiler look for both '\n' and ';' for parsering?

example: why not let this be legal

int main()
{
printf("HELLO!");int i = 1
i = 22
while(i < 32)
{
printf("%i",i);
i++;
}
return 0
}

the only downside to this is that, with a mix of semicolons and no semicolons, the code could look messy.

"imr1984" <imr1984_member@pathlink.com> wrote in message news:c2n4fj$lva$1@digitaldaemon.com...
> the other day i was studying assembly programming, and it struck me - why
does D
> need semicolons after statements at all? they seem like a waste of time.
>
> I think statements should be seperated by new lines OR semicolons, so that existing D code will still work.
>
> Ive been programming C style languages for years now and i still often
forget a
> semicolon - so i think this would be a big time saver, as well as making
the
> code more readable

This is exactly what javascript does. Since I have implemented a javascript compiler, DMDScript, I have some experience with how this works.

It doesn't work too well :-(

One winds up with some wierd parsing ambiguities that get resolved by fiat. Error detection and recovery is adversely affected, as there is less redundancy in the grammar. Worst of all, having newline be sometimes whitespace and sometimes a statement separator breaks the clean separation between the tokenizer and the parser.

Ant wrote:

> On Wed, 10 Mar 2004 16:11:01 +0100, Sigbjørn Lund Olsen wrote:
> 
> 
>>The most annoying syntax error I tend to make is when I forget to close a literal string somewhere.
> 
> 
> (Ah! another opportunity to talk about leds.)
> 
> leds will highlight unclosed literals with a different color.
> (This is standard on Scintilla)
> 
> Ant
> 

Oh, yes, syntax highlighting...

I guess I just have a thing for EditPad :-o

Seriously, though, I haven't yet found a syntax highlighting editor that  let's me much about with every little detail, generally resulting in me becoming unhappy with some nitpicky detail and uninstalling. Not that I've looked very hard.

(There, now you can talk more about leds :-p)

Cheers,
Sigbjørn Lund Olsen

kinghajj wrote:
> why can't the compiler look for both '\n' and ';' for parsering?
> 
> example: why not let this be legal
> 
> int main()
> {
> printf("HELLO!");int i = 1
> i = 22
> while(i < 32)
> {
> printf("%i",i);
> i++;
> }
> return 0
> }
> 
> the only downside to this is that, with a mix of semicolons and no semicolons,
> the code could look messy.

Have you ever worked on a project that had more than a few hundred lines of javascript?

The biggest javascript project I worked on had about 30,000 lines and was far from the largest in my company.

Maintaining that many lines of code with a flaky grammar is a royal pain. (And let's not even get into bugs like:
this.test = 1; if(this.testT) alert("it's good")

Believe me being messy is not the only downside. When it comes to software engineering, consistency and maintainability are big issues.

Besides, Walter wants line terminators. :-)

-- 
Alex

On Thu, 11 Mar 2004 02:48:22 +0100, Sigbjørn Lund Olsen wrote:

> Seriously, though, I haven't yet found a syntax highlighting editor that
>   let's me much about with every little detail, generally resulting in
> me becoming unhappy with some nitpicky detail and uninstalling.

hey!, just build your own!

or better yet pick an open source one and boost it up ;) ever hear about leds?...

> 
> (There, now you can talk more about leds :-p)
> 

:)

Ant

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c2nbmv$15cs$1@digitaldaemon.com...
> It would raise the ambiguity even further. While languages like Python (which has line-based formatting) and Eiffel (which ignores line ends, but semicolons are optional) can afford that, i think C-like languages cannot. This would cause too much ambiguity and lead to even more stupid bugs! Don't you have enough of ambiguities?
>
> Don't see how it would be besser to readability.
>
> -eye

I agree, it would take much more time to read code.

For instance a for loop:
for(int i = 0 i < somthin i++)

Even that small amount of code is much harder to read than this:
for(int i = 0; i < somthin; i++)

In my opinion it would be like taking the full stops
out of sentences.

Phill


>
>
> imr1984 schrieb:
>
> > the other day i was studying assembly programming, and it struck me -
why does D
> > need semicolons after statements at all? they seem like a waste of time.
> >
> > I think statements should be seperated by new lines OR semicolons, so
that
> > existing D code will still work.
> >
> > Ive been programming C style languages for years now and i still often
forget a
> > semicolon - so i think this would be a big time saver, as well as making
the
> > code more readable
> >
> >

Phill wrote:
> "Ilya Minkov" <minkov@cs.tum.edu> wrote in message
> news:c2nbmv$15cs$1@digitaldaemon.com...
> 
>>It would raise the ambiguity even further. While languages like Python
>>(which has line-based formatting) and Eiffel (which ignores line ends,
>>but semicolons are optional) can afford that, i think C-like languages
>>cannot. This would cause too much ambiguity and lead to even more stupid
>>bugs! Don't you have enough of ambiguities?
>>
>>Don't see how it would be besser to readability.
>>
>>-eye
> 
> 
> I agree, it would take much more time to read code.
> 
> For instance a for loop:
> for(int i = 0 i < somthin i++)
> 
> Even that small amount of code is much harder to read than this:
> for(int i = 0; i < somthin; i++)
> 
> In my opinion it would be like taking the full stops
> out of sentences.

now that you mention it that is a very good point i think that semi colons are as important to d as periods and other punctuation marks are essential to written communications in english actually i find it quite difficult to either read or write without using punctuation i think it might be easier to get the code to compile but that doesnt count for much if it doesnt run right and is unmaintainable as always though your mileage may vary

> 
> Phill


-- 
Justin
http://jcc_7.tripod.com/d/