- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.1] #11043

by Andreas Wacknitz

I cannot see updates 11038 and 11039. Neither my own updated image nor this new one show these updates. Transcript show: ScriptLoader new logStream contents shows that there is a gap in the updates... Andreas Am 14.11.2009 um 16:51 schrieb Marcus Denker: > 11043 > ----- > > Issue 1441: Add a protection in MCDefinition = > Issue 1439: Parse should not use typeTable ivar but #typeTableAt: message > Issue 1440: Monticello packageList speed up > > Marcus > > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 14, 2009

Re: [Pharo-project] Status about compiler _ changes

by Nicolas Cellier

Folks, I suggest we follow solution 1 in order to not be stuck. Then we will add backward compatibility hacks if necessary and if not too much ugly. Agree ? Nicolas 2009/11/14 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/11/14 Adrian Lienhard <adi(a)netstyle.ch>: >> OK, then, we do Lukas' option 1: "change the scanner for 1.1 without >> fallback". >> >> Adrian >> >> >> On Nov 14, 2009, at 16:38 , Schwab,Wilhelm K wrote: >> >>> I feel somewhat responsible for this branch of the thread :( Â For >>> the record, I am freely willing to "give up" underscore assignment. >>> The idea of allowing it via a whitespace trick seemed worthy of due >>> consideration, but I am liking it less as the debate continues. >>> >>> IIRC, the whole mess got started over a desire to have a single >>> keypress for assignment. Â Sadly, I was not consulted, because that >>> could have been accomplished as an optional feature of the editor (_ >>> inserts :=, backing up over = removes a preceding :, turn it off if >>> you want Â no part of it; done), but it was instead allowed to seep >>> into the compiler and the sources. >>> >>> It can't go away too soon for my tastes, but a transition period >>> makes sense too. Â Whatever you guys want to do is fine by me. >>> Thanks for tackling the problem!! >>> >>> Bill >>> >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >>> ] On Behalf Of Lukas Renggli >>> Sent: Saturday, November 14, 2009 4:01 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Status about compiler _ changes >>> >>>>> (2) it complicates the scanning significantly, the same token >>>>> represents different things depending on context and an extended >>>>> lookahead is required to parse it, >>>> >>>> I'm afraid I'm not seeing this point. From a brief look at the >>>> scanner, it appears that allowing := assignment did complicate the >>>> scanner somewhat, but that allowing _ to mean assignment should be >>>> similar complexity and still only require one-char lookahead. But >>>> perhaps I'm missing something. >>> >>> You need to make sure that there is a delimiter (or comment) before >>> and after the underscore character, which I think is not trivial to >>> scan. Certainly possible, but not trivial. >>> >>> Furthermore it would make it impossible to write code like >>> >>> Â Â a _ b >>> >>> where a is a variable, #_ and #b are unary messages. The above code >>> is valid in other Smalltalk dialects. >>> >>>>> and (3) it allows that people >>>>> continue to use crappy underscore assignments, there will be a mess >>>>> forever. >>>> >>>> I can't (and don't want to) argue with that :-) I'll gladly accept >>>> "we >>>> don't want to allow underscore assignment" as an argument, I'm not so >>>> sure about the "it's hard" argument. >>> >>> I am not saying it is impossible. >>> >>> My main concerns are the following: >>> >>> 1. I don't like that _ means different things depending on context. >>> 2. I don't like that the use of _ in identifiers has unnecessary >>> restrictions and exceptions. >>> 3. I don't want to break compatibility with other Smalltalk dialects. >>> 4. I don't want to see _ as assignment operator anymore. >>> 5. I don't want to rewrite the complete compiler, there are probably >>> more changes coming from Eliot for closures, the stack VM and the JIT. >>> I don't want to make integrating those unnecessarily hard. >>> 6. I don't want to break irreparably other tools that depend on the >>> Smalltalk syntax like the Refactoring Engine or the NewCompiler. >>> >>> Lukas >>> > > I'm quite sure we can handle this via notifications or errors and > appropriate handlers with very few hacks in Compiler/Parser. > This would occur only in batch mode. > > For example: > - emit a warning when #'_' message is sent > - handle in batch-mode handler by setting a flag > (doesUseUnderscoreAsAMessage) and let the code proceed > - let handler restart compilation with a modified typeTable if another > Error/Warning is issued > > Nicolas. > >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Nov. 14, 2009

[Pharo-project] Monticello load order

by Nicolas Cellier

I notice a subtle difference with trunk in the load order: Trunk does: 1) class def 2) compile new/changed methods 3) install new methods 4) remove methods (classes) 5) retry errors 6) notify 7) postload (initialize) Pharo does almost the same but delay method installation 3) after steps 4) and 5) 1) class def 2) compile new/changed methods 3) remove methods (classes) 4) retry errors 5) install new methods 6) notify 7) postload (initialize) Both solution might suffer from problems when changing a core package... The question is: is one better than the other? My opinion is that pharo has problems with refactorings: if I rename a core method, then it will be first removed before the new one be installed and that might prevent a package to load. What do you think ?

Nov. 14, 2009

[Pharo-project] [ann] pre-built core 1.1#11043

by Marcus Denker

http://gforge.inria.fr/frs/download.php/24763/PharoCore-1.1-11043-alpha.zip

Nov. 14, 2009

Re: [Pharo-project] Status about compiler _ changes

by Nicolas Cellier

2009/11/14 Adrian Lienhard <adi(a)netstyle.ch>: > OK, then, we do Lukas' option 1: "change the scanner for 1.1 without > fallback". > > Adrian > > > On Nov 14, 2009, at 16:38 , Schwab,Wilhelm K wrote: > >> I feel somewhat responsible for this branch of the thread :( Â For >> the record, I am freely willing to "give up" underscore assignment. >> The idea of allowing it via a whitespace trick seemed worthy of due >> consideration, but I am liking it less as the debate continues. >> >> IIRC, the whole mess got started over a desire to have a single >> keypress for assignment. Â Sadly, I was not consulted, because that >> could have been accomplished as an optional feature of the editor (_ >> inserts :=, backing up over = removes a preceding :, turn it off if >> you want Â no part of it; done), but it was instead allowed to seep >> into the compiler and the sources. >> >> It can't go away too soon for my tastes, but a transition period >> makes sense too. Â Whatever you guys want to do is fine by me. >> Thanks for tackling the problem!! >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Lukas Renggli >> Sent: Saturday, November 14, 2009 4:01 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Status about compiler _ changes >> >>>> (2) it complicates the scanning significantly, the same token >>>> represents different things depending on context and an extended >>>> lookahead is required to parse it, >>> >>> I'm afraid I'm not seeing this point. From a brief look at the >>> scanner, it appears that allowing := assignment did complicate the >>> scanner somewhat, but that allowing _ to mean assignment should be >>> similar complexity and still only require one-char lookahead. But >>> perhaps I'm missing something. >> >> You need to make sure that there is a delimiter (or comment) before >> and after the underscore character, which I think is not trivial to >> scan. Certainly possible, but not trivial. >> >> Furthermore it would make it impossible to write code like >> >> Â Â a _ b >> >> where a is a variable, #_ and #b are unary messages. The above code >> is valid in other Smalltalk dialects. >> >>>> and (3) it allows that people >>>> continue to use crappy underscore assignments, there will be a mess >>>> forever. >>> >>> I can't (and don't want to) argue with that :-) I'll gladly accept >>> "we >>> don't want to allow underscore assignment" as an argument, I'm not so >>> sure about the "it's hard" argument. >> >> I am not saying it is impossible. >> >> My main concerns are the following: >> >> 1. I don't like that _ means different things depending on context. >> 2. I don't like that the use of _ in identifiers has unnecessary >> restrictions and exceptions. >> 3. I don't want to break compatibility with other Smalltalk dialects. >> 4. I don't want to see _ as assignment operator anymore. >> 5. I don't want to rewrite the complete compiler, there are probably >> more changes coming from Eliot for closures, the stack VM and the JIT. >> I don't want to make integrating those unnecessarily hard. >> 6. I don't want to break irreparably other tools that depend on the >> Smalltalk syntax like the Refactoring Engine or the NewCompiler. >> >> Lukas >> I'm quite sure we can handle this via notifications or errors and appropriate handlers with very few hacks in Compiler/Parser. This would occur only in batch mode. For example: - emit a warning when #'_' message is sent - handle in batch-mode handler by setting a flag (doesUseUnderscoreAsAMessage) and let the code proceed - let handler restart compilation with a modified typeTable if another Error/Warning is issued Nicolas. >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 14, 2009

Re: [Pharo-project] Status about compiler _ changes

by Adrian Lienhard

OK, then, we do Lukas' option 1: "change the scanner for 1.1 without fallback". Adrian On Nov 14, 2009, at 16:38 , Schwab,Wilhelm K wrote: > I feel somewhat responsible for this branch of the thread :( For > the record, I am freely willing to "give up" underscore assignment. > The idea of allowing it via a whitespace trick seemed worthy of due > consideration, but I am liking it less as the debate continues. > > IIRC, the whole mess got started over a desire to have a single > keypress for assignment. Sadly, I was not consulted, because that > could have been accomplished as an optional feature of the editor (_ > inserts :=, backing up over = removes a preceding :, turn it off if > you want no part of it; done), but it was instead allowed to seep > into the compiler and the sources. > > It can't go away too soon for my tastes, but a transition period > makes sense too. Whatever you guys want to do is fine by me. > Thanks for tackling the problem!! > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Lukas Renggli > Sent: Saturday, November 14, 2009 4:01 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Status about compiler _ changes > >>> (2) it complicates the scanning significantly, the same token >>> represents different things depending on context and an extended >>> lookahead is required to parse it, >> >> I'm afraid I'm not seeing this point. From a brief look at the >> scanner, it appears that allowing := assignment did complicate the >> scanner somewhat, but that allowing _ to mean assignment should be >> similar complexity and still only require one-char lookahead. But >> perhaps I'm missing something. > > You need to make sure that there is a delimiter (or comment) before > and after the underscore character, which I think is not trivial to > scan. Certainly possible, but not trivial. > > Furthermore it would make it impossible to write code like > > a _ b > > where a is a variable, #_ and #b are unary messages. The above code > is valid in other Smalltalk dialects. > >>> and (3) it allows that people >>> continue to use crappy underscore assignments, there will be a mess >>> forever. >> >> I can't (and don't want to) argue with that :-) I'll gladly accept >> "we >> don't want to allow underscore assignment" as an argument, I'm not so >> sure about the "it's hard" argument. > > I am not saying it is impossible. > > My main concerns are the following: > > 1. I don't like that _ means different things depending on context. > 2. I don't like that the use of _ in identifiers has unnecessary > restrictions and exceptions. > 3. I don't want to break compatibility with other Smalltalk dialects. > 4. I don't want to see _ as assignment operator anymore. > 5. I don't want to rewrite the complete compiler, there are probably > more changes coming from Eliot for closures, the stack VM and the JIT. > I don't want to make integrating those unnecessarily hard. > 6. I don't want to break irreparably other tools that depend on the > Smalltalk syntax like the Refactoring Engine or the NewCompiler. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 14, 2009

Re: [Pharo-project] Status about compiler _ changes

by Schwab,Wilhelm K

Marcus, The left arrow is part of it, but single-key assignment was the big reason given to not fix it. The important thing is that Pharo is going to get it right. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Marcus Denker Sent: Saturday, November 14, 2009 10:48 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Status about compiler _ changes On Nov 14, 2009, at 4:38 PM, Schwab,Wilhelm K wrote: > I feel somewhat responsible for this branch of the thread :( For the record, I am freely willing to "give up" underscore assignment. The idea of allowing it via a whitespace trick seemed worthy of due consideration, but I am liking it less as the debate continues. > > IIRC, the whole mess got started over a desire to have a single keypress for assignment. Sadly, I was not consulted, because that could have been accomplished as an optional feature of the editor (_ inserts :=, backing up over = removes a preceding :, turn it off if you want no part of it; done), but it was instead allowed to seep into the compiler and the sources. > No, the _ used to be rendered as a left-arrow. This comes from a time far, far away when there where less standards...build-your-own keyboad times. It was a left-over from Smalltalk 72 which had lots of graphical characters as part of the language. The _ was removed from all Smalltalks, just not from Squeak. This was because it felt to certain people that going ascii was a mistake anyway and that more graphical stuff should come again, not less. And removing the left-arrow betrays that vision. The fun thing is: I am all for experiments to go beyond text. But than it should be *real*. Just keeping the _ as a kind of "look, we are special" is idiotic. So we removed the funny character left-arrow and let it render what the _ (so people can deal with external code, c, or database rows...). Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 14, 2009

Re: [Pharo-project] MailMessage

by Schwab,Wilhelm K

Marco, Does that imply that you have had success otherwise? How did you send the mail? I _think_ it ultimately goes through SMTPClient, but it's a real rats' nest and I could be missing something. Also, how did you create the message? Most of the examples seem to have the headers created "in the text" as opposed to generating them from supplied aspects :( Interestingly, I am having trouble sending a plain-text message from Pharo. I _have_ had success sending an attachment. I have not bothered to see if I can read the result, but the server delivered it, and LookOut!! seems to think there is something attached to the message. The weird thing is that my attemps to send plain text resulted in (superficially at least) a reasonable conversation with the server (I added enough tracing to see the sends and the server's responses). The server reports accepting the message for delivery, but it never arrrives. I am **reasonbly** certain my email address is correct, but obviously that is something that needs to be re-re-re-checked. Something in Mantis made reference to <> around email addresses; I think it was only in the case of multiple recipients, but it is worth a look. The server reports itself as sendmail, but it would not surprise me if it another piece of Microsoft crap-ware that claims to be something it is not. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schmidt, Marco Sent: Friday, November 13, 2009 3:42 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] MailMessage I had a problem with Email and the character encoding. Sending mail with the character 'ÃÃÃ' inside the mail body killed the mail server. So - look at correct encoding of the message text. Marco Schmidt -----UrsprÃ¼ngliche Nachricht----- Von: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im Auftrag von Schwab,Wilhelm K Gesendet: Freitag, 13. November 2009 01:29 An: Pharo-project(a)lists.gforge.inria.fr Betreff: [Pharo-project] MailMessage Hello all, I am looking for a way to format text in email. Html comes to mind (yes, I hate those emails too, but it would work and the recipients don't know any better<g>), as does attaching a file with the data. I recently had to switch smtp servers, and for whatever reason, can no longer send html email. The server says it accepted it, but the mail is never delivered; send plain text through it, and it works. It could simply be that the server wants no part of html email, but it would be nice to repeat the test with another client, and/or try attachments as a solution to my problem. I found MailMessage, and could not figure out how to set the recipient. After some searching, I found 151 on Mantis; it is a five year old fix from Frank Shearer for adding recipients. If I had to guess, things are still broken, but I will try it and see what happens. Sending this now while I'm thinking about it. If anybody knows a way around my current problems, please don't feel that you would be cheating me out of the fun of solving it myself :) Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 14, 2009

[Pharo-project] [update 1.1] #11043

by Marcus Denker

11043 ----- Issue 1441: Add a protection in MCDefinition = Issue 1439: Parse should not use typeTable ivar but #typeTableAt: message Issue 1440: Monticello packageList speed up Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 14, 2009

Re: [Pharo-project] Project removal continued

by Marcus Denker

On Nov 13, 2009, at 6:52 PM, StÃ©phane Ducasse wrote: > http://code.google.com/p/pharo/issues/detail?id=1438 > > > Another batch ready > integrated. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 14, 2009