Please test...
https://gforge.inria.fr/frs/download.php/29274/Pharo-1.3-13315-OneClick.zip -- Marcus Denker -- http://marcusdenker.de |
On Wed, Oct 19, 2011 at 2:20 PM, Marcus Denker <[hidden email]> wrote: Please test... -- Mariano http://marianopeck.wordpress.com |
Moose is building now using this image.
It looks quite good. The only issue seems to be with RoelTyper when trying to type the variables from AST-Core. But, I did not investigate this in details yet. Cheers, Doru On 19 Oct 2011, at 14:53, Mariano Martinez Peck wrote: > > > On Wed, Oct 19, 2011 at 2:20 PM, Marcus Denker <[hidden email]> wrote: > Please test... > > https://gforge.inria.fr/frs/download.php/29274/Pharo-1.3-13315-OneClick.zip > > -- > Marcus Denker -- http://marcusdenker.de > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Live like you mean it." |
I still get the error handling failure when attempting
HtmlParser parse:Clipboard default clipboardText readStream. Again, the expression is wrong, but it should give only a walkback, not the preceding error. ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Tudor Girba [[hidden email]] Sent: Wednesday, October 19, 2011 2:29 PM To: [hidden email] Cc: A friendly place where any question about pharo is welcome Subject: Re: [Pharo-project] [ANN 1.3] One-Click #13315 Moose is building now using this image. It looks quite good. The only issue seems to be with RoelTyper when trying to type the variables from AST-Core. But, I did not investigate this in details yet. Cheers, Doru On 19 Oct 2011, at 14:53, Mariano Martinez Peck wrote: > > > On Wed, Oct 19, 2011 at 2:20 PM, Marcus Denker <[hidden email]> wrote: > Please test... > > https://gforge.inria.fr/frs/download.php/29274/Pharo-1.3-13315-OneClick.zip > > -- > Marcus Denker -- http://marcusdenker.de > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Live like you mean it." |
Oh I can reproduce this one easily: Just do this: | buf out | buf := ByteArray new: 1024. out := NullStream new. (ZLibWriteStream on: out) nextPutAll: buf. (the 'out' stream should have been binary in order for the code to be correct) |
That's helpful to illustrate the problem. Of course, the concern is not that the code is wrong (no argument there), it's the fact that 1.3 goes nuts rather than simply displaying a walkback.
1.4 exhibits the same defect. My 1.1.1 image "gets it right," (goes directly to the walkback), but that is using a non-Cog vm. ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of mmimica [[hidden email]] Sent: Saturday, October 22, 2011 5:33 AM To: [hidden email] Subject: Re: [Pharo-project] [ANN 1.3] One-Click #13315 Schwab,Wilhelm K wrote: > > I still get the error handling failure when attempting > > HtmlParser parse:Clipboard default clipboardText readStream. > > Again, the expression is wrong, but it should give only a walkback, not > the preceding error. > Oh I can reproduce this one easily: Just do this: | buf out | buf := ByteArray new: 1024. out := NullStream new. (ZLibWriteStream on: out) nextPutAll: buf. (the 'out' stream should have been binary in order for the code to be correct) -- View this message in context: http://forum.world.st/ANN-1-3-One-Click-13315-tp3918441p3927851.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. |
Heh, to make it more apsurd, this trivial code does the job. And is actually correct.
| out | out := NullStream new. self break. On 22 October 2011 16:43, Schwab,Wilhelm K <[hidden email]> wrote: That's helpful to illustrate the problem. Of course, the concern is not that the code is wrong (no argument there), it's the fact that 1.3 goes nuts rather than simply displaying a walkback. Milan Mimica http://sparklet.sf.net |
On 22 Oct 2011, at 17:21, Milan Mimica wrote: > Heh, to make it more apsurd, this trivial code does the job. And is actually correct. > | out | > out := NullStream new. > self break. NullStream new is unprintable which seems to trigger the emergency evaluator when entering the debugger. Since the inspector can live with unprintable objects, so should the debugger. Has this already been turned into an issue ? If not, I will do it. Sven |
In reply to this post by Marcus Denker-4
Marcus Denker wrote:
> Please test... > > https://gforge.inria.fr/frs/download.php/29274/Pharo-1.3-13315-OneClick.zip > > -- > Marcus Denker -- http://marcusdenker.de > I've spent the weekend trying to isolate a VM crash varying the conditions under which pharo.exe runs. The user steps to reproduce are minimal: 1. Run pharo.exe 2. Open TestRunner 3. Click <Run Selected> ...but this leaves a lot of possibilities. I have Windows 7 and I usually operate under a non-admin account, but also did testing with an admin account. I got the feeling the problem is network related. During the test run a Windows Security Alert regarding the firewall blocking functionality would appear, and a fair while later the VM would crash. It seems under a non-admin account the OS then choses to deny by default because for subsequent runs of pharo.exe, the WSA did not appear and also the image did not crash the first time <Run Selected> was clicked from TestRunner, but a second click of <Run Selected> would still crash the image. I'm not sure on the list policy of attaching a 1.7MB file with report and crash dumps, so for interested parties I have sent the file direct to Marcus. cheers, Ben |
Ben Coman wrote:
> Marcus Denker wrote: >> Please test... >> >> https://gforge.inria.fr/frs/download.php/29274/Pharo-1.3-13315-OneClick.zip >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> > I've spent the weekend trying to isolate a VM crash varying the > conditions under which pharo.exe runs. The user steps to reproduce > are minimal: > 1. Run pharo.exe > 2. Open TestRunner > 3. Click <Run Selected> > ...but this leaves a lot of possibilities. > > I have Windows 7 and I usually operate under a non-admin account, but > also did testing with an admin account. I got the feeling the problem > is network related. During the test run a Windows Security Alert > regarding the firewall blocking functionality would appear, and a fair > while later the VM would crash. It seems under a non-admin account > the OS then choses to deny by default because for subsequent runs of > pharo.exe, the WSA did not appear and also the image did not crash the > first time <Run Selected> was clicked from TestRunner, but a second > click of <Run Selected> would still crash the image. > > I'm not sure on the list policy of attaching a 1.7MB file with report > and crash dumps, > so for interested parties I have sent the file direct to Marcus. > > cheers, Ben Testcase that produced it ? |
Hi. There was some crash related to network changes... but I don't remember that much. Maybe Sven can help you.
Attach here the dump file and the PharoDebug.log no problem. Did you also try in pharo 1.4 ? just to see if it works there. thanks On Sun, Oct 30, 2011 at 3:49 PM, Ben Coman <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
In reply to this post by Ben Coman
On Oct 30, 2011, at 4:00 PM, Mariano Martinez Peck wrote: > Hi. There was some crash related to network changes... but I don't remember that much. Maybe Sven can help you. > Attach here the dump file and the PharoDebug.log no problem. That should have been fixed in 13315... Now what would be nice is to run automatically all tests on the last VM on all three architectures. Will we ever reach that goal? Marcus -- Marcus Denker -- http://marcusdenker.de |
In reply to this post by Mariano Martinez Peck
Pharo 1.4 works okay, which is great the crash is avoided, but with
only 8804 tests versus 9757 in Pharo 1.3 it is unclear whether:
1. Bug has been fixed in VM. 2. System Code has been removed from image 3. Test Code exercising the crash has been removed from image Ideally the problem doesn't just go away by itself :) otherwise it might be scenario 2. or 3. above rather than 1 :) However I then reran Pharo-1.3 image with no crash - so a null experiment. For your records, I did the following... a. extracted Pharo-1.3-13315-OneClick.zip b. extracted Pharo-1.4-14210.zip into the Resource folder, c. renamed pharo.exe & pharo.ini to pharo14.exe & pharo14.ini as described in my previous report d. modified pharo14.ini with ImageFile=Contents\Resources\pharo-1.4.image e. ran pharo14.exe, opened TestRunner and clicked <Run Selected>, then later clicked <Run Selected> a second time. f. Quit g. modified pharo14.ini with ImageFile=Contents\Resources\pharo.image h. ran pharo14.exe, opened TestRunner and clicked <Run Selected> i. Quit Mariano Martinez Peck wrote: Hi. There was some crash related to network changes... but I don't remember that much. Maybe Sven can help you. |
In reply to this post by Marcus Denker-4
Yes we will :)
On Oct 30, 2011, at 4:04 PM, Marcus Denker wrote: > > On Oct 30, 2011, at 4:00 PM, Mariano Martinez Peck wrote: > >> Hi. There was some crash related to network changes... but I don't remember that much. Maybe Sven can help you. >> Attach here the dump file and the PharoDebug.log no problem. > > That should have been fixed in 13315... > > Now what would be nice is to run automatically all tests on the last VM on all three architectures. > Will we ever reach that goal? > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > |
In reply to this post by Mariano Martinez Peck
On Oct 30, 2011, at 5:31 PM, Ben Coman wrote: > Pharo 1.4 works okay, which is great the crash is avoided, but with only 8804 tests versus 9757 in Pharo 1.3 it is unclear whether: > 1. Bug has been fixed in VM. > 2. System Code has been removed from image > 3. Test Code exercising the crash has been removed from image > Ideally the problem doesn't just go away by itself :) otherwise it might be scenario 2. or 3. above rather than 1 :) > > However I then reran Pharo-1.3 image with no crash - so a null experiment. > > For your records, I did the following... > a. extracted Pharo-1.3-13315-OneClick.zip > b. extracted Pharo-1.4-14210.zip into the Resource folder, > c. renamed pharo.exe & pharo.ini to pharo14.exe & pharo14.ini as described in my previous report > d. modified pharo14.ini with ImageFile=Contents\Resources\pharo-1.4.image > e. ran pharo14.exe, opened TestRunner and clicked <Run Selected>, then later clicked <Run Selected> a second time. > f. Quit > g. modified pharo14.ini with ImageFile=Contents\Resources\pharo.image > h. ran pharo14.exe, opened TestRunner and clicked <Run Selected> > i. Quit -> Does it happen Core 1.3? -> Does it happen with other VMs? Marcus -- Marcus Denker -- http://marcusdenker.de |
Hello!
Some weeks ago i asked, weather code in Smalltalk is an object too or not. The answers were not that clear as i expected! :-( Now i would like to put up the question, if there is a paradigm change in software engineering slowly coming up in the Smalltalk community towards class factory, code, that generates code, that is jitted immediately to generate further classes to finally be instantiated? E.g. the regexp compilercompiler SmaCC. How "dense" has a Smalltalk code system to be that it starts to emerge from itself? Means: When starts Pharo refactoring its own code or AST parser itself? Maybe a too unclear question, but i hope someone can understand what i mean ... :-) tnx in advance, Guido Stepken |
In reply to this post by Marcus Denker-4
On Oct 31, 2011, at 11:16 AM, Guido Stepken wrote: > Hello! > > Some weeks ago i asked, weather code in Smalltalk is an object too or not. The answers were not that clear as i expected! :-( > > Now i would like to put up the question, if there is a paradigm change in software engineering slowly coming up in the Smalltalk community towards class factory, code, that generates code, that is jitted immediately to generate further classes to finally be instantiated? > Would that be good? Meta Programming is powerful, but you need to take care that you can produce an un-understandable mess very easily. > E.g. the regexp compilercompiler SmaCC. Nobody uses SmaCC anymore. > How "dense" has a Smalltalk code system to be that it starts to emerge from itself? > That is another question. > Means: When starts Pharo refactoring its own code or AST parser itself? > PetitParser provides exactly that: A parser has a meta-model to be changed at runtime. With Opal, we use an AST for everything that has transformation support of the RB. > Maybe a too unclear question, but i hope someone can understand what i mean ... :-) > You are always confusing. Marcus -- Marcus Denker -- http://marcusdenker.de |
In reply to this post by Guido Stepken
On Oct 31, 2011, at 11:16 AM, Guido Stepken wrote: > Hello! > > Some weeks ago i asked, weather code in Smalltalk is an object too or not. The answers were not that clear as i expected! :-( > > Now i would like to put up the question, if there is a paradigm change in software engineering slowly coming up in the Smalltalk community towards class factory, code, that generates code, that is jitted immediately to generate further classes to finally be instantiated? not specially > E.g. the regexp compilercompiler SmaCC. How "dense" has a Smalltalk code system to be that it starts to emerge from itself? > > Means: When starts Pharo refactoring its own code or AST parser itself? But it does. Pharo does not use Smacc. > Maybe a too unclear question, but i hope someone can understand what i mean ... :-) > > tnx in advance, Guido Stepken |
In reply to this post by Marcus Denker-4
> >> Means: When starts Pharo refactoring its own code or AST parser itself? >> > PetitParser provides exactly that: A parser has a meta-model to be changed at runtime. > > With Opal, we use an AST for everything that has transformation support of the RB. > > >> Maybe a too unclear question, but i hope someone can understand what i mean ... :-) >> > You are always Hi Marcus! PetitParser ... Yes. A paradigm chance already. I was thinking of a data flow analysis parser, that "profiles" through a running system, looking out for relevant and irrelevant "data control & logic structures" (like reducing Pharo source from "unused" code), backtracking the growing of finally thrown or unused data, thus reducing the system to the minimum of relevant code by itself. Means - I see a new paradigm change coming up. Is's like sticking "PetitParser" in its own ass, letting PetitParser analyze its own dataflow, automatically replacing PetitParser by its evolutionary child. What source structures could be generated, that are still readable and changeable by humans?? Guido |
In reply to this post by Marcus Denker-4
Happy to try, but I don't know where to get Core or other VMs.On Oct 30, 2011, at 5:31 PM, Ben Coman wrote:Pharo 1.4 works okay, which is great the crash is avoided, but with only 8804 tests versus 9757 in Pharo 1.3 it is unclear whether: 1. Bug has been fixed in VM. 2. System Code has been removed from image 3. Test Code exercising the crash has been removed from image Ideally the problem doesn't just go away by itself :) otherwise it might be scenario 2. or 3. above rather than 1 :) However I then reran Pharo-1.3 image with no crash - so a null experiment. For your records, I did the following... a. extracted Pharo-1.3-13315-OneClick.zip b. extracted Pharo-1.4-14210.zip into the Resource folder, c. renamed pharo.exe & pharo.ini to pharo14.exe & pharo14.ini as described in my previous report d. modified pharo14.ini with ImageFile=Contents\Resources\pharo-1.4.image e. ran pharo14.exe, opened TestRunner and clicked <Run Selected>, then later clicked <Run Selected> a second time. f. Quit g. modified pharo14.ini with ImageFile=Contents\Resources\pharo.image h. ran pharo14.exe, opened TestRunner and clicked <Run Selected> i. QuitWhat would be interesting: -> Does it happen Core 1.3? -> Does it happen with other VMs? Marcus |
Free forum by Nabble | Edit this page |