- Pharo-dev - lists.pharo.org

[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

[Pharo 8.0] Build #594: UFFI-test-cases-should-end-with-Test

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

There is a new Pharo build available! The status of the build #594 was: FAILURE. The Pull Request #4176 was integrated: "UFFI-test-cases-should-end-with-Test" Pull request url: https://github.com/pharo-project/pharo/pull/4176 Issue Url: https://github.com/pharo-project/pharo/issues/UFFI Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 4, 2019

[Pharo 8.0] Build #593: Test-cases-should-end-with-Test-instead-of-Tests

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

There is a new Pharo build available! The status of the build #593 was: FAILURE. The Pull Request #4187 was integrated: "Test-cases-should-end-with-Test-instead-of-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/4187 Issue Url: https://github.com/pharo-project/pharo/issues/Test Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 4, 2019

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

by Javier PimÃ¡s

Just in time :P This is really cool! On Fri, Aug 2, 2019 at 1:10 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > 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 > > > -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 3, 2019