March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo Portable was Re: one-click is dead, now we have platform specific builds

by MartinW

Dennis Groves wrote > >>> yes, the procedure is still there, and it is still possible to produce >>> one-click distributions... >>> maybe we could produce a "portable" version (I think the portable >>> concept captures better what a one-click is... because a one click is >>> not a one click, you still need to double click on it :D ) > > >> That might be a smart marketing move. PortableApps have become quite >> popular, and are an advantage within a locked down corporate >> environment. It is a term people are familiar with and that helps >> newcomers comfort level. > > > This is why I like it, I can throw it on my USB and have it run anywhere > - my tools go with me where ever I need them. :-) Yes, keeping the formerly-known-as-one-click version as a "portable" version would be very nice. I am currently carrying one with me on a usb-stick between my mac and other peoples windows pcs. This works very well. -- View this message in context: http://forum.world.st/one-click-is-dead-now-we-have-platform-specific-build… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 21, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Andrei Vasile Chis

> Once I have a problem loading something from SS3 which was a piece of source > code with non-utf8 characters (WideString). > Could it be possible you have some non-utf characters in the source of the > package you are loading? I will check, however it happes for a lot of packages. Some work, and some do not work. @Sven I have a linux installation on virtual box where I could reproduce this problem. I can give you access to it. > > > On Thu, Mar 21, 2013 at 10:08 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: >> >> Andrei, >> >> On 21 Mar 2013, at 13:28, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> >> wrote: >> >> > Hi Sven, >> > >> > I tried all the command from your previous mail and the results are >> > the same (output bellow). >> >> Thanks for the feedback. >> >> > The strange thing is that I can download other files from smalltalkhub >> > without problems. >> >> What do you mean, that it only fails for that particular mcz file from >> StHub in Pharo, but that others are OK ? >> That would be very disturbing. Can you give an example of a call that does >> work, with the Transcript output, like >> >> ZnClient new >> logToTranscript; >> setAcceptEncodingGzip; >> get: >> 'http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD…'; >> response. >> >> 2013-03-20 23:17:17 995343 I Wrote a ZnRequest(GET >> /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz) >> 2013-03-20 23:17:17 995343 D Sent headers >> User-Agent: Zinc HTTP Components 1.0 >> Accept-Encoding: gzip >> Host: www.smalltalkhub.com >> Accept: */* >> >> 2013-03-20 23:17:17 995343 I Read a ZnResponse(200 OK >> application/x-monticello 3451B) >> 2013-03-20 23:17:17 995343 D Received headers >> Date: Wed, 20 Mar 2013 22:17:18 GMT >> Content-Encoding: gzip >> Transfer-Encoding: chunked >> Content-Length: 3451 >> Vary: Accept-Encoding >> Server: KomHttpServer/7.1.3 (unix) >> Content-Type: application/x-monticello >> >> 2013-03-20 23:17:17 995343 T GET >> /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz 200 >> 3451B 272ms >> >> > A short summary: >> > >> > ZnEntityReader>>#readEntity calls ZnEntityReader>>#readEntityFromStream >> > which does 'GZipReadStream on: stream', after which >> > 'readFrom:usingType:andLength:' is called. >> > In a wrong call, 'GZipReadStream on: stream' always throws >> > ConnectionClosed. This is handled in >> > ZnClient>>executeWithRetriesRemaining: >> > which keeps retrying until retryCount is 0. On the other hand for some >> > files 'GZipReadStream on: stream' >> > returns correctly, no exception is raised and it works ok. >> > >> > The exception is thrown in Socket>>waitForDataFor:ifClosed:ifTimedOut: >> > because Socket>>primSocketConnectionStatus: >> > returns 3 instead of 2. >> > [(Time millisecondsSince: startTime) < msecsDelta] whileTrue: [ >> > "here 'self primSocketConnectionStatus: socketHandle' is >> > 2" >> > (self primSocketReceiveDataAvailable: socketHandle) >> > ifTrue: [Transcript crShow: ' hasData'. ^self]. >> > "here 'self primSocketConnectionStatus: socketHandle' is >> > 3, if >> > there is no more content to be read >> > so 'self isConnected' will be false." >> > self isConnected >> > ifFalse: [Transcript crShow: ' >> > notConnected'.^closedBlock value]. >> > self readSemaphore waitTimeoutMSecs: >> > (msecsDelta - (Time millisecondsSince: startTime) >> > max: 0). >> > ]. >> > >> > That fact that this exception is raised during the call to >> > 'GZipReadStream on: stream' seem to be the problem, >> > as this does not allow readFrom: stream usingType: self contentType >> > andLength: >> > >> > I hope this makes sense. >> >> We probably do not have to look in the socket[stream] layer, the first >> place to look is in ZnEntityReader, more specifically: what was the >> situation wrt headers before it starts reading the body, what decisions were >> taken, and how far was/is it in the reading process. >> >> > I can try to dig more into it tomorrow. >> > If you want me to look at other things let me know. >> >> I am wondering whether we could set some temporary screen sharing over the >> internet, so that I can remotely work in an image running on a machine in >> your networkâ¦ >> >> Sven >> >> > Cheers, >> > Andrei >> > >> > >> > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> > >> > $ curl >> > http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… >> > -H "Accept-Encoding: gzip" | gunzip > foo.mcz >> > % Total % Received % Xferd Average Speed Time Time Time >> > Current >> > Dload Upload Total Spent Left >> > Speed >> > 100 3307 0 3307 0 0 7583 0 --:--:-- --:--:-- --:--:-- >> > 8889 >> > >> > $ file foo.mcz >> > foo.mcz: Zip archive data, at least v2.0 to extract >> > >> > $ ls -l foo.mcz >> > -rw-r--r-- 1 andrei staff 3451 Mar 21 09:55 foo.mcz >> > >> > $ unzip -l foo.mcz >> > Archive: foo.mcz >> > Length Date Time Name >> > -------- ---- ---- ---- >> > 18 03-27-11 02:22 package >> > 188 03-27-11 02:22 version >> > 8588 03-27-11 02:22 snapshot/source.st >> > 9014 03-27-11 02:22 snapshot.bin >> > -------- ------- >> > 17808 4 files >> > >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com

March 21, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Mariano Martinez Peck

Once I have a problem loading something from SS3 which was a piece of source code with non-utf8 characters (WideString). Could it be possible you have some non-utf characters in the source of the package you are loading? Cheers, On Thu, Mar 21, 2013 at 10:08 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > Andrei, > > On 21 Mar 2013, at 13:28, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> > wrote: > > > Hi Sven, > > > > I tried all the command from your previous mail and the results are > > the same (output bellow). > > Thanks for the feedback. > > > The strange thing is that I can download other files from smalltalkhub > > without problems. > > What do you mean, that it only fails for that particular mcz file from > StHub in Pharo, but that others are OK ? > That would be very disturbing. Can you give an example of a call that does > work, with the Transcript output, like > > ZnClient new > logToTranscript; > setAcceptEncodingGzip; > get: ' > http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… > '; > response. > > 2013-03-20 23:17:17 995343 I Wrote a ZnRequest(GET > /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz) > 2013-03-20 23:17:17 995343 D Sent headers > User-Agent: Zinc HTTP Components 1.0 > Accept-Encoding: gzip > Host: www.smalltalkhub.com > Accept: */* > > 2013-03-20 23:17:17 995343 I Read a ZnResponse(200 OK > application/x-monticello 3451B) > 2013-03-20 23:17:17 995343 D Received headers > Date: Wed, 20 Mar 2013 22:17:18 GMT > Content-Encoding: gzip > Transfer-Encoding: chunked > Content-Length: 3451 > Vary: Accept-Encoding > Server: KomHttpServer/7.1.3 (unix) > Content-Type: application/x-monticello > > 2013-03-20 23:17:17 995343 T GET > /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz 200 > 3451B 272ms > > > A short summary: > > > > ZnEntityReader>>#readEntity calls ZnEntityReader>>#readEntityFromStream > > which does 'GZipReadStream on: stream', after which > > 'readFrom:usingType:andLength:' is called. > > In a wrong call, 'GZipReadStream on: stream' always throws > > ConnectionClosed. This is handled in > > ZnClient>>executeWithRetriesRemaining: > > which keeps retrying until retryCount is 0. On the other hand for some > > files 'GZipReadStream on: stream' > > returns correctly, no exception is raised and it works ok. > > > > The exception is thrown in Socket>>waitForDataFor:ifClosed:ifTimedOut: > > because Socket>>primSocketConnectionStatus: > > returns 3 instead of 2. > > [(Time millisecondsSince: startTime) < msecsDelta] whileTrue: [ > > "here 'self primSocketConnectionStatus: socketHandle' is > 2" > > (self primSocketReceiveDataAvailable: socketHandle) > > ifTrue: [Transcript crShow: ' hasData'. ^self]. > > "here 'self primSocketConnectionStatus: socketHandle' is > 3, if > > there is no more content to be read > > so 'self isConnected' will be false." > > self isConnected > > ifFalse: [Transcript crShow: ' > notConnected'.^closedBlock value]. > > self readSemaphore waitTimeoutMSecs: > > (msecsDelta - (Time millisecondsSince: startTime) > max: 0). > > ]. > > > > That fact that this exception is raised during the call to > > 'GZipReadStream on: stream' seem to be the problem, > > as this does not allow readFrom: stream usingType: self contentType > andLength: > > > > I hope this makes sense. > > We probably do not have to look in the socket[stream] layer, the first > place to look is in ZnEntityReader, more specifically: what was the > situation wrt headers before it starts reading the body, what decisions > were taken, and how far was/is it in the reading process. > > > I can try to dig more into it tomorrow. > > If you want me to look at other things let me know. > > I am wondering whether we could set some temporary screen sharing over the > internet, so that I can remotely work in an image running on a machine in > your networkâ¦ > > Sven > > > Cheers, > > Andrei > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > $ curl > http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… > > -H "Accept-Encoding: gzip" | gunzip > foo.mcz > > % Total % Received % Xferd Average Speed Time Time Time > Current > > Dload Upload Total Spent Left > Speed > > 100 3307 0 3307 0 0 7583 0 --:--:-- --:--:-- --:--:-- > 8889 > > > > $ file foo.mcz > > foo.mcz: Zip archive data, at least v2.0 to extract > > > > $ ls -l foo.mcz > > -rw-r--r-- 1 andrei staff 3451 Mar 21 09:55 foo.mcz > > > > $ unzip -l foo.mcz > > Archive: foo.mcz > > Length Date Time Name > > -------- ---- ---- ---- > > 18 03-27-11 02:22 package > > 188 03-27-11 02:22 version > > 8588 03-27-11 02:22 snapshot/source.st > > 9014 03-27-11 02:22 snapshot.bin > > -------- ------- > > 17808 4 files > > > > > -- Mariano http://marianopeck.wordpress.com

March 21, 2013

Re: [Pharo-project] Pharo Portable was Re: one-click is dead, now we have platform specific builds

by Dennis Groves

On 21 Mar 2013, at 13:22, Ben Coman wrote: > That might be a smart marketing move. PortableApps have become quite > popular, and are an advantage within a locked down corporate > environment. It is a term people are familiar with and that helps > newcomers comfort level. This is why I like it, I can throw it on my USB and have it run anywhere - my tools go with me where ever I need them. :-) -- [Dennis Groves](http://about.me/dennis.groves), MSc [Email me](mailto:dennis.groves@owasp.org) or [schedule a meeting](http://goo.gl/8sPIy). *This email is licensed under a [CC BY-ND 3.0](http://creativecommons.org/licenses/by-nd/3.0/deed.en_GB) license.* **Please do not send me Microsoft Office/Apple iWork documents.** Send [OpenDocument](http://fsf.org/campaigns/opendocument/) instead! Stand up for your freedom to install [free software](http://www.fsf.org/campaigns/secure-boot/statement). > The idea that some lives matter less is the root of all thatâs wrong > with the world. -- Paul Farmer

March 21, 2013

[Pharo-project] Pharo Portable was Re: one-click is dead, now we have platform specific builds

by Ben Coman

That might be a smart marketing move. PortableApps have become quite popular, and are an advantage within a locked down corporate environment. It is a term people are familiar with and that helps newcomers comfort level. -ben Esteban Lorenzano wrote: > Hi Sean, > > yes, the procedure is still there, and it is still possible to produce one-click distributions... > maybe we could produce a "portable" version (I think the portable concept captures better what a one-click is... because a one click is not a one click, you still need to double click on it :D ) > > Esteban > > On Mar 20, 2013, at 12:43 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > > >> EstebanLM wrote >> >>> I just adapted the script for create one-click >>> >> Have we captured the procedure for the one-click? Even though it didn't work >> out for newbies, I think it has value in other contexts e.g. a personal >> image that I can easily start up on any OS, perhaps to show off at >> conferences ;) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/one-click-is-dead-now-we-have-platform-specific-build… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > >

March 21, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Sven Van Caekenberghe

Andrei, On 21 Mar 2013, at 13:28, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > Hi Sven, > > I tried all the command from your previous mail and the results are > the same (output bellow). Thanks for the feedback. > The strange thing is that I can download other files from smalltalkhub > without problems. What do you mean, that it only fails for that particular mcz file from StHub in Pharo, but that others are OK ? That would be very disturbing. Can you give an example of a call that does work, with the Transcript output, like ZnClient new logToTranscript; setAcceptEncodingGzip; get: 'http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD…'; response. 2013-03-20 23:17:17 995343 I Wrote a ZnRequest(GET /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz) 2013-03-20 23:17:17 995343 D Sent headers User-Agent: Zinc HTTP Components 1.0 Accept-Encoding: gzip Host: www.smalltalkhub.com Accept: */* 2013-03-20 23:17:17 995343 I Read a ZnResponse(200 OK application/x-monticello 3451B) 2013-03-20 23:17:17 995343 D Received headers Date: Wed, 20 Mar 2013 22:17:18 GMT Content-Encoding: gzip Transfer-Encoding: chunked Content-Length: 3451 Vary: Accept-Encoding Server: KomHttpServer/7.1.3 (unix) Content-Type: application/x-monticello 2013-03-20 23:17:17 995343 T GET /mc/AndreiChis/AnnouncerCentricDebugger/main/ACD-Tests-AndreiChis.1.mcz 200 3451B 272ms > A short summary: > > ZnEntityReader>>#readEntity calls ZnEntityReader>>#readEntityFromStream > which does 'GZipReadStream on: stream', after which > 'readFrom:usingType:andLength:' is called. > In a wrong call, 'GZipReadStream on: stream' always throws > ConnectionClosed. This is handled in > ZnClient>>executeWithRetriesRemaining: > which keeps retrying until retryCount is 0. On the other hand for some > files 'GZipReadStream on: stream' > returns correctly, no exception is raised and it works ok. > > The exception is thrown in Socket>>waitForDataFor:ifClosed:ifTimedOut: > because Socket>>primSocketConnectionStatus: > returns 3 instead of 2. > [(Time millisecondsSince: startTime) < msecsDelta] whileTrue: [ > "here 'self primSocketConnectionStatus: socketHandle' is 2" > (self primSocketReceiveDataAvailable: socketHandle) > ifTrue: [Transcript crShow: ' hasData'. ^self]. > "here 'self primSocketConnectionStatus: socketHandle' is 3, if > there is no more content to be read > so 'self isConnected' will be false." > self isConnected > ifFalse: [Transcript crShow: ' notConnected'.^closedBlock value]. > self readSemaphore waitTimeoutMSecs: > (msecsDelta - (Time millisecondsSince: startTime) max: 0). > ]. > > That fact that this exception is raised during the call to > 'GZipReadStream on: stream' seem to be the problem, > as this does not allow readFrom: stream usingType: self contentType andLength: > > I hope this makes sense. We probably do not have to look in the socket[stream] layer, the first place to look is in ZnEntityReader, more specifically: what was the situation wrt headers before it starts reading the body, what decisions were taken, and how far was/is it in the reading process. > I can try to dig more into it tomorrow. > If you want me to look at other things let me know. I am wondering whether we could set some temporary screen sharing over the internet, so that I can remotely work in an image running on a machine in your networkâ¦ Sven > Cheers, > Andrei > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > $ curl http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… > -H "Accept-Encoding: gzip" | gunzip > foo.mcz > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 3307 0 3307 0 0 7583 0 --:--:-- --:--:-- --:--:-- 8889 > > $ file foo.mcz > foo.mcz: Zip archive data, at least v2.0 to extract > > $ ls -l foo.mcz > -rw-r--r-- 1 andrei staff 3451 Mar 21 09:55 foo.mcz > > $ unzip -l foo.mcz > Archive: foo.mcz > Length Date Time Name > -------- ---- ---- ---- > 18 03-27-11 02:22 package > 188 03-27-11 02:22 version > 8588 03-27-11 02:22 snapshot/source.st > 9014 03-27-11 02:22 snapshot.bin > -------- ------- > 17808 4 files >

March 21, 2013

Re: [Pharo-project] Problem downloading packages with Monticello from Smalltalkhub because of setAcceptEncodingGzip

by Andrei Vasile Chis

Hi Sven, I tried all the command from your previous mail and the results are the same (output bellow). The strange thing is that I can download other files from smalltalkhub without problems. A short summary: ZnEntityReader>>#readEntity calls ZnEntityReader>>#readEntityFromStream which does 'GZipReadStream on: stream', after which 'readFrom:usingType:andLength:' is called. In a wrong call, 'GZipReadStream on: stream' always throws ConnectionClosed. This is handled in ZnClient>>executeWithRetriesRemaining: which keeps retrying until retryCount is 0. On the other hand for some files 'GZipReadStream on: stream' returns correctly, no exception is raised and it works ok. The exception is thrown in Socket>>waitForDataFor:ifClosed:ifTimedOut: because Socket>>primSocketConnectionStatus: returns 3 instead of 2. [(Time millisecondsSince: startTime) < msecsDelta] whileTrue: [ "here 'self primSocketConnectionStatus: socketHandle' is 2" (self primSocketReceiveDataAvailable: socketHandle) ifTrue: [Transcript crShow: ' hasData'. ^self]. "here 'self primSocketConnectionStatus: socketHandle' is 3, if there is no more content to be read so 'self isConnected' will be false." self isConnected ifFalse: [Transcript crShow: ' notConnected'.^closedBlock value]. self readSemaphore waitTimeoutMSecs: (msecsDelta - (Time millisecondsSince: startTime) max: 0). ]. That fact that this exception is raised during the call to 'GZipReadStream on: stream' seem to be the problem, as this does not allow readFrom: stream usingType: self contentType andLength: I hope this makes sense. I can try to dig more into it tomorrow. If you want me to look at other things let me know. Cheers, Andrei ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ $ curl http://www.smalltalkhub.com/mc/AndreiChis/AnnouncerCentricDebugger/main/ACD… -H "Accept-Encoding: gzip" | gunzip > foo.mcz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3307 0 3307 0 0 7583 0 --:--:-- --:--:-- --:--:-- 8889 $ file foo.mcz foo.mcz: Zip archive data, at least v2.0 to extract $ ls -l foo.mcz -rw-r--r-- 1 andrei staff 3451 Mar 21 09:55 foo.mcz $ unzip -l foo.mcz Archive: foo.mcz Length Date Time Name -------- ---- ---- ---- 18 03-27-11 02:22 package 188 03-27-11 02:22 version 8588 03-27-11 02:22 snapshot/source.st 9014 03-27-11 02:22 snapshot.bin -------- ------- 17808 4 files

March 21, 2013

Re: [Pharo-project] one-click is dead, now we have platform specific builds

by Dennis Groves

On 21 Mar 2013, at 5:41, Marcus Denker wrote: > On 20.03.2013, at 22:54, "Dennis Groves" <dennis.groves(a)gmail.com> > wrote: > >> To whom it may concern, >> >> I have an opinion: >> I for one prefer the one-click on OSX. It just fits into the >> environment better. >> > > Did you try the macos version of the non-oneclick? It is the same as > before, minus the windows and linux binaries. 3.0 works quite nicely after I perform the edit described in my bug. :-) Dennis -- [Dennis Groves](http://about.me/dennis.groves), MSc [Email me](mailto:dennis.groves@owasp.org) or [schedule a meeting](http://goo.gl/8sPIy). *This email is licensed under a [CC BY-ND 3.0](http://creativecommons.org/licenses/by-nd/3.0/deed.en_GB) license.* **Please do not send me Microsoft Office/Apple iWork documents.** Send [OpenDocument](http://fsf.org/campaigns/opendocument/) instead! Stand up for your freedom to install [free software](http://www.fsf.org/campaigns/secure-boot/statement). > The idea that some lives matter less is the root of all thatâs wrong > with the world. -- Paul Farmer

March 21, 2013

Re: [Pharo-project] one-click is dead, now we have platform specific builds

by Dennis Groves

On 21 Mar 2013, at 8:08, Camillo Bruni wrote: >> can you add a issue tracker entry? > > yes I already reported it: > > https://pharo.fogbugz.com/default.asp?10062#72825 Thank you, I haven't ever used fogbugz before, as I tend to avoid all non-open source software. :-) Dennis -- [Dennis Groves](http://about.me/dennis.groves), MSc [Email me](mailto:dennis.groves@owasp.org) or [schedule a meeting](http://goo.gl/8sPIy). *This email is licensed under a [CC BY-ND 3.0](http://creativecommons.org/licenses/by-nd/3.0/deed.en_GB) license.* **Please do not send me Microsoft Office/Apple iWork documents.** Send [OpenDocument](http://fsf.org/campaigns/opendocument/) instead! Stand up for your freedom to install [free software](http://www.fsf.org/campaigns/secure-boot/statement). > The idea that some lives matter less is the root of all thatâs wrong > with the world. -- Paul Farmer

March 21, 2013

Re: [Pharo-project] Petit parser UI

by Norbert Hartl

Am 21.03.2013 um 11:21 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > Hi Norbert, > > Indeed, this was one of the main new additions to Moose. Lukas helped with the refactoring support and I rebuilt the browser to show that you can have a Glamour browser without and explicit UI model. It seems that it works :). > > I am happy you like it. The point about variables is a good one. Could you please add it to the Moose issue tracker? https://code.google.com/p/moose-technology/issues/detail?id=920 > > But, I think it can still be improved further. The goal is to have the developer only use this browser during development, without needing the Pharo system browser. We are almost there, but not quite. > > In general, I am interested in any experience of using the browser and in learning when it falls short and makes you have to use the system browser. > > One thing that is utterly missing is the support for testing. PetitParser comes with a beautiful support for tests and I would like to bring these tests close to the productions. > Those sound like good ideas. In my case it was a debugging issue. I needed to go back to my grammar and look why certain snippets cannot be parsed. So avoiding the system browser isn't the right goal here. What helped is the separation of example text and matching pane. Switching to the debugger was very helpful because the grammar is utterly complex and I don't know what something is meant to be most of the time. In the debugger you can follow the parsing and figure out easily what has been matched. That is even the way I developed my test cases. I don't have a repository for productions and test data. So I took live data followed the debugger and his matches. From that I verified things by hand and then I did a test case for it. I was missing an inspector that gives me an inspector of the parsed model but I found it while writing the first mail :) Norbert > > On Mar 21, 2013, at 9:54 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Whoever changed petit parser UI in the last couple month: Very good job! After some time working in a new image with new versions I opened the UI and was very pleased that most of the things I was missing in the old UI are there now. >> >> To me there is less to improveâ¦waitâ¦.maybe two little things: >> >> - The pane that lets you choose the production rule shows all instance variables of the selected parser class. In case I have a derived parser class where not every selector is overwritten I don't have a chance to select the rule. Would it be a good to show all instance variables of all class in the hierarchy above the petit parser classes? >> - Applying the â¦ â¦ what's that "i" button above the lower right pane? Haha, just found what I was looking for. Screw that point. Make it one little thing! >> >> Norbert >> >> > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > >

March 21, 2013