June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] MC breakage in 1.1

by Gary Chambers

Surely the http response could be used to generate an appropriate exception/return-value to be handled in the domain (Monticello itself). I've not tripped myself up recently on the credential thing but, from memory, it was clear that credentials were the issue. Regards, Gary ----- Original Message ----- From: "Dale Henrichs" <dhenrich(a)vmware.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, June 15, 2010 6:11 PM Subject: Re: [Pharo-project] MC breakage in 1.1 In GLASS, I have arranged to prompt for new/missing credentials when the save fails due to an HTTP error ... It's a bit of a hack, since the HTTP client doesn't throw an error, but it is better than the alternative ... only experts know how to fix the credentials using the debugger:) In my case I wanted to minimize changes to the HTTP client, but I would think that for Pharo, explicit error handling would be an improvement for the HTTP client anyway... Dale StÃ©phane Ducasse wrote: > before reverting it > could we not have another solution ;) > Because indeed I never went inside the debugger to catch the credentials > Stef > > > On Jun 15, 2010, at 9:25 AM, HernÃ¡n Morales Durand wrote: > >> 2010/6/15 Lukas Renggli <renggli(a)gmail.com>: >>>> This is because "2" should not be created. If a copy cannot be saved >>>> then there is no reason to increment the version number with the >>>> failed attempt. May deserve another issue entry? >>>> >>>> Please comment I would like to read opinions on this. >>> I noticed this problem too. The previous behavior was better, at least >>> if you knew how to fix you credentials in the debugger. >>> >> Ok then revert the change if you like, although the Debugger is >> probably the most powerful tool we have I see it as a tool for editing >> code, not configurations (I've never heard of anyone going though >> Debugger to set credentials in MC) and newbies may perceive a problem >> with MC instead of their settings or network problems. >> >> HernÃ¡n >> >> _______________________________________________ >> 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

June 15, 2010

Re: [Pharo-project] MC breakage in 1.1

by Dale Henrichs

In GLASS, I have arranged to prompt for new/missing credentials when the save fails due to an HTTP error ... It's a bit of a hack, since the HTTP client doesn't throw an error, but it is better than the alternative ... only experts know how to fix the credentials using the debugger:) In my case I wanted to minimize changes to the HTTP client, but I would think that for Pharo, explicit error handling would be an improvement for the HTTP client anyway... Dale StÃ©phane Ducasse wrote: > before reverting it > could we not have another solution ;) > Because indeed I never went inside the debugger to catch the credentials > Stef > > > On Jun 15, 2010, at 9:25 AM, HernÃ¡n Morales Durand wrote: > >> 2010/6/15 Lukas Renggli <renggli(a)gmail.com>: >>>> This is because "2" should not be created. If a copy cannot be saved >>>> then there is no reason to increment the version number with the >>>> failed attempt. May deserve another issue entry? >>>> >>>> Please comment I would like to read opinions on this. >>> I noticed this problem too. The previous behavior was better, at least >>> if you knew how to fix you credentials in the debugger. >>> >> Ok then revert the change if you like, although the Debugger is >> probably the most powerful tool we have I see it as a tool for editing >> code, not configurations (I've never heard of anyone going though >> Debugger to set credentials in MC) and newbies may perceive a problem >> with MC instead of their settings or network problems. >> >> HernÃ¡n >> >> _______________________________________________ >> 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

June 15, 2010

[Pharo-project] Squeak on iPad (2)

by Torsten Bergmann

More here: http://croquetweak.blogspot.com/2010/06/squeak-etoys-on-ipad.html "Morphic was designed to handle multiple "hands" (pointing devices) from the beginning" I hope we didnt remove that while cleaning morphic, so Pharo could also be made multitouch-aware. Bye T. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

June 15, 2010

Re: [Pharo-project] Issue 2555: WideString asByteString does not return a ByteString

by Henrik Johansen

On Jun 15, 2010, at 12:09 09PM, StÃ©phane Ducasse wrote: > Reported by nils.winter, Today (2 hours ago) > WideString asByteString does not return a ByteString. > > Pharo image: Pharo > Pharo core version: Pharo-1.1-11367-Beta > Virtual machine used: Squeak 4.2.4beta1U > Class browser used (if applicable): OBSystemBrowserAdaptor > > > Steps to reproduce: > > 1. 'Ï' asByteString isByteString "false, shouldn't that be true?" > > Shouldn't that at least fail? I would suspect, that String>>asByteString should be something like > > asByteString > | string | > "Convert the receiver into a ByteString" > string := ByteString new: self byteSize. > 1 to: self byteSize do: [: i | string byteAt: i put: (self byteAt: i)]. > ^string > > (copied that from asOctedString and replaced #size, #at:put: and #at: with their byte-versions > ) > > btw: The display of 'Ï' seems to be broken on 1.1 is displayed as '?? and has some strange cursor issued but functionality is there > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Responded in detail in the issue. Basically, asByteString is a bad name for what it does/should be allowed to do. Zero senders, not sure if we should keep it for backwards-compat or just remove it (asOctetString is more descriptive with the same functionality as current). Either way I added a slice with some better comments explaining its limitations. Cheers, Henry

June 15, 2010

Re: [Pharo-project] AutoStart startUp:

by Pavel Krivanek

Hi Stef, I atteched the changeset to the issue. Cheers, -- Pavel On Tue, Jun 15, 2010 at 12:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > http://code.google.com/p/pharo/issues/detail?id=2556 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 15, 2010

Re: [Pharo-project] SmaCC

by Tudor Girba

Hi, Moose is a platform for analysis of data in general and software systems in particular. It is not specific to Smalltalk or to any other language. It does come with prebuilt solutions for modeling and parsing various languages, but you can extend it with your own specific requirements. To form a generic idea, you can browse a bit this: http://themoosebook.org/ Regarding the reference to GLMTabulator, you need Glamour (which indeed also ships with Moose). If you want to load PetitParser with all required dependencies you do it via this script: Gofer new renggli: 'petit'; package: 'ConfigurationOfPetitParser'; load. (Smalltalk at: #ConfigurationOfPetitParser) perform: #loadDefault. Cheers, Doru On 15 Jun 2010, at 00:46, Alexandre Bergel wrote: >> I started reading about Moose (esp Meta-environment and executable >> meta-language using smalltalk) and it was all about languages with >> introspection. SAS has no such ability, and is not even object >> oriented. So it didn't seem like a good fit. Have I >> misunderstood--for >> example, are the remarks directed more at smalltalk as an >> implementation >> language for Moose? > > As soon as you provide a parser and a meta-model for your language, > then moose is your friend. Independently if your language is object- > oriented or not. > I build an importer for C for Moose. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

June 15, 2010

Re: [Pharo-project] AutoStart startUp:

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2556

June 15, 2010

[Pharo-project] Issue 2555: WideString asByteString does not return a ByteString

by StÃ©phane Ducasse

Reported by nils.winter, Today (2 hours ago) WideString asByteString does not return a ByteString. Pharo image: Pharo Pharo core version: Pharo-1.1-11367-Beta Virtual machine used: Squeak 4.2.4beta1U Class browser used (if applicable): OBSystemBrowserAdaptor Steps to reproduce: 1. 'Ï' asByteString isByteString "false, shouldn't that be true?" Shouldn't that at least fail? I would suspect, that String>>asByteString should be something like asByteString | string | "Convert the receiver into a ByteString" string := ByteString new: self byteSize. 1 to: self byteSize do: [: i | string byteAt: i put: (self byteAt: i)]. ^string (copied that from asOctedString and replaced #size, #at:put: and #at: with their byte-versions ) btw: The display of 'Ï' seems to be broken on 1.1 is displayed as '?? and has some strange cursor issued but functionality is there

June 15, 2010

Re: [Pharo-project] [SPAM] Fwd: [Pharo-users] [SPAM] Re: WebClient

by StÃ©phane Ducasse

excellent news! thanks him for us Stef On Jun 15, 2010, at 10:19 AM, Sven Van Caekenberghe wrote: > > On 14 Jun 2010, at 16:48, StÃ©phane Ducasse wrote: > >>> I will contact Andreas directly once I know your position on the last remaining item. >> >> Good > > I did contact Andreas Raab and he integrated both of my patch sets upstream so that WebClient-Core now load and works on Pharo 1.1rc2 without the need for any Pharo specific patches. > > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 15, 2010

Re: [Pharo-project] Alien for 1.1

by StÃ©phane Ducasse

it depends if people have a fix or not. if this is just the recreate special object array we can integrate a new one as soon as we get one. Stef > Hi, > > I failed to load Alien on 1.1. Then, I went to the googleCode rep and found that the issue was already reported. But, it's tagged for 1.2. Does it mean that we'll have to live without Alien in 1.1? > > see issues: > 1360 ---- Accepted Add Alien in 1.2 Milestone=1.2 difficulty=Important > 2452 ---- Accepted recreate special object array Milestone=1.2 difficulty=Important > > Noury > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 15, 2010