August 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

by Christophe Demarey

Hi Sean, > Le 26 juil. 2019 Ã 15:23, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > demarey wrote >> we want more feedback before promoting it. > > "Show in folder" doesn't work - still trying to use OSProcess which appears > to no longer be loaded. BTW IMHO it would be better to create a layer to > hide the process differences on different OSes. This new world of a > different lib for each OS is hopefully a milestone on a path to a more > unified future, and it will be harder to clean out all the "if windows" > conditionals later. True. I also discovered that juste after the 1.9.1 release. Thatâs why I did the 1.9.2 release (see https://github.com/pharo-project/pharo-launcher/releases/tag/1.9.2 <https://github.com/pharo-project/pharo-launcher/releases/tag/1.9.2>). It is fixed in this version. Christophe.

Aug. 6, 2019

Re: [Pharo-dev] Two Surprising and Scary FS Behaviors

by ducasse

I like your analysis because indeed it can bring bad news. Can you turn this behaviour into memory file system tests? So that we make sure that we should find a solution. Stf > On 6 Aug 2019, at 00:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I may be ignorant of some key principle in the filesystem world, but IMHO > conceptually, `location / somethingElse` should always return either > location or something inside of it, unless the request explicitly requests > otherwise (e.g. location / '..'). To do otherwise could be disastrous. > > Behavior #1 > rootDataFolder := FileLocator home / 'a' / 'b' / . > subfolderName := self accidentallyReturnAnEmptyString. > assumedToBeInRootData := rootDataFolder / subfolderName. > assumedToBeInRootData deleteAll. > > "I hope I have a recent machine backup, because..." > assumedToBeInRootData resolve = FileLocator root resolve. "WTH?!" > > Behavior 2 (similar) > Path * 'a' / 'b' / '/' = Path root. "WTH?!" > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Aug. 6, 2019

Two Surprising and Scary FS Behaviors

by Sean P. DeNigris

I may be ignorant of some key principle in the filesystem world, but IMHO conceptually, `location / somethingElse` should always return either location or something inside of it, unless the request explicitly requests otherwise (e.g. location / '..'). To do otherwise could be disastrous. Behavior #1 rootDataFolder := FileLocator home / 'a' / 'b' / . subfolderName := self accidentallyReturnAnEmptyString. assumedToBeInRootData := rootDataFolder / subfolderName. assumedToBeInRootData deleteAll. "I hope I have a recent machine backup, because..." assumedToBeInRootData resolve = FileLocator root resolve. "WTH?!" Behavior 2 (similar) Path * 'a' / 'b' / '/' = Path root. "WTH?!" ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 5, 2019

[Pharo 8.0] Build #596: 4137-Code-completion-error

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #596 was: FAILURE. The Pull Request #4175 was integrated: "4137-Code-completion-error" Pull request url: https://github.com/pharo-project/pharo/pull/4175 Issue Url: https://github.com/pharo-project/pharo/issues/4137 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 5, 2019

[Pharo 8.0] Build #595: Refactor a few tests to new classes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #595 was: FAILURE. The Pull Request #4189 was integrated: "Refactor a few tests to new classes" Pull request url: https://github.com/pharo-project/pharo/pull/4189 Issue Url: https://github.com/pharo-project/pharo/issues/refactor_tests Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 5, 2019

Re: [Pharo-dev] Some new bindings for native emulation stuff

by Norbert Hartl

There is much sense in this mail, I like it. The unicorn GPL shouldnât be an issue in this usage scenario. Well done, Norbert > Am 05.08.2019 um 11:48 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > >> El 3 ago 2019, a las 13:59, Norbert Hartl <norbert(a)hartl.name> escribiÃ³: >> >> That is pretty awesome. Couldnât be an constraint umbrella for VMMaker. This way it would be possible to write tests that check for resulting code. Or writing tests for the JIT (does sista has something like this). Could be one step closer to a deterministic code generation, no? > > Just to be fair, there are in Cog machine code simulation capabilities by using Bochs for intel and gdb 7.10 for arm32. > And there is also a starting point for testing the JIT. > > However, we have seen that for this the opensmalltalk-vm contains a copy of bochs and gdb source code > https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/processors > > And with Pablo we have thought this was a suboptimal (both regarding building and licencingâ¦), so we started to look at alternatives. > Thatâs why we took a look at unicorn and llvm. Unicorn is ultimately based on qemu, which is fairly mature from our point of view. > There is not much to say about llvm :). > > What is nice is that with a single set of bindings we can cover lots of platforms. E.g., no need for new bindings for arm64. > > Aaand, with some little adjustments here and there, we have ~85% of 114 existing tests passing for arm32, x86 and x86-64. > <PastedGraphic-6.png> > > Of course there are not many tests, and they are only testing the basic compiler (just instructions) and not the Jitting of methods. > But itâs a good start. > > Now, also we were a bit picky about licensing: > - The llvm disassembler bindings are MIT. > - We have licensed the unicorn bindings as LGPL because Unicorn is GPL, and this would allow people to use the bindings without any requirements on licensing. However, any modifications to the bindings or unicorn itself should be further published as LGPL or GPL. > > Guille > >> >> Norbert >> >>> Am 02.08.2019 um 18:09 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> Hi everybody, >>> >>> Iâve been playing around with machine code simulation this last week and Iâve made bindings for the unicorn library and the llvm disassembler: >>> >>> https://github.com/guillep/pharo-unicorn >>> https://github.com/guillep/pharo-llvmDisassembler >>> >>> Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits and moreâ¦). So out of the box we can simulate and disassemble lots of platforms. >>> >>> And in one afternoon Iâve played with them to do a native debugger with Spec2 just for fun. >>> Hope this evolves a bit more soon, and that it helps somebody. >>> >>> Guille >>> >>> <PastedGraphic-5.png> >>> >

Aug. 5, 2019

Looking for project using System-History

by ClÃ©ment Dutriez

Hello, I'm looking for a project using the Pharo System-History (class HistoryNode, HistoryLeaf). I want to use it in the fileDialog can someone send me a link to his project? Thank you in advance. -- Dutriez ClÃ©ment dutriezcle(a)gmail.com 0605199489 [image: www.linkedin.com/in/clÃ©ment-dutriez-407275173] <http://www.linkedin.com/in/clÃ©ment-dutriez-407275173>

Aug. 5, 2019

Re: [Pharo-dev] Some new bindings for native emulation stuff

by Guillermo Polito

> El 3 ago 2019, a las 13:59, Norbert Hartl <norbert(a)hartl.name> escribiÃ³: > > That is pretty awesome. Couldnât be an constraint umbrella for VMMaker. This way it would be possible to write tests that check for resulting code. Or writing tests for the JIT (does sista has something like this). Could be one step closer to a deterministic code generation, no? Just to be fair, there are in Cog machine code simulation capabilities by using Bochs for intel and gdb 7.10 for arm32. And there is also a starting point for testing the JIT. However, we have seen that for this the opensmalltalk-vm contains a copy of bochs and gdb source code https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/processors <https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/processors> And with Pablo we have thought this was a suboptimal (both regarding building and licencingâ¦), so we started to look at alternatives. Thatâs why we took a look at unicorn and llvm. Unicorn is ultimately based on qemu, which is fairly mature from our point of view. There is not much to say about llvm :). What is nice is that with a single set of bindings we can cover lots of platforms. E.g., no need for new bindings for arm64. Aaand, with some little adjustments here and there, we have ~85% of 114 existing tests passing for arm32, x86 and x86-64. Of course there are not many tests, and they are only testing the basic compiler (just instructions) and not the Jitting of methods. But itâs a good start. Now, also we were a bit picky about licensing: - The llvm disassembler bindings are MIT. - We have licensed the unicorn bindings as LGPL because Unicorn is GPL, and this would allow people to use the bindings without any requirements on licensing. However, any modifications to the bindings or unicorn itself should be further published as LGPL or GPL. Guille > > Norbert > > Am 02.08.2019 um 18:09 schrieb Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > >> Hi everybody, >> >> Iâve been playing around with machine code simulation this last week and Iâve made bindings for the unicorn library and the llvm disassembler: >> >> https://github.com/guillep/pharo-unicorn <https://github.com/guillep/pharo-unicorn> >> https://github.com/guillep/pharo-llvmDisassembler <https://github.com/guillep/pharo-llvmDisassembler> >> >> Funny thing: both support lots of platforms (x86 and arm both 32 and 64 bits and moreâ¦). So out of the box we can simulate and disassemble lots of platforms. >> >> And in one afternoon Iâve played with them to do a native debugger with Spec2 just for fun. >> Hope this evolves a bit more soon, and that it helps somebody. >> >> Guille >> >> <PastedGraphic-5.png> >>

Aug. 5, 2019

Re: [Pharo-dev] Breakpoint restart error

by Thomas Dupriez

Hi ben, If you don't touch the new error and keep stepping over in the original debugger, it does not get confused. It's not really a "solution" though, merely an observation. The issue is not related to the restart. It comes from stepping over a message with a breakpoint. For example, if you also set a breakpoint on the "b := 2" node and step over it, there is the same issue. Example code: Object compile: 'myTest2 Â |a b c| Â a := 1. Â b := 2. Â c := 3'. Breakpoint new node: (Object>>#myTest2) ast; install. Breakpoint new node: (Object>>#myTest2) ast children first statements second; install. "Installing breakpoint on node b := 2" Object new myTest2. "<over>, <over>, <over> -> issue" In your example, here's what happens: - you run the test - the breakpoint triggers, and stops the execution - you step over two times - you restart, which means the next code to be executed is now the breakpoint that was inserted at the start of the test method - you step over a breakpoint, which causes the issue. A very similar issue occurs when stepping over a 'self halt'. Cheers, Thomas On 04/08/2019 17:09, Ben Coman wrote: > I trying to set a breakpoint programatically so that users can be > dropped into the custom script they can add to a system. I try... > > Object compile: 'myTest > Â |a b c| > Â a := 1. > Â b := 2. > Â c := 3'. > Breakpoint new node: (Object>>#myTest) ast; install. > Object new myTest. > "click <over>Â <over>Â <restart> <over>" > > but the following error appears and the debugger gets confused... > image.png > > What am I doing wrong? > > cheers -ben

Aug. 5, 2019

Breakpoint restart error

by Ben Coman

I trying to set a breakpoint programatically so that users can be dropped into the custom script they can add to a system. I try... Object compile: 'myTest |a b c| a := 1. b := 2. c := 3'. Breakpoint new node: (Object>>#myTest) ast; install. Object new myTest. "click <over> <over> <restart> <over>" but the following error appears and the debugger gets confused... [image: image.png] What am I doing wrong? cheers -ben

Aug. 4, 2019