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

Functional callbacks on all Cog platforms

by Eliot Miranda

Hi All, just wanted to report that as of Alien-eem.35 and https://github.com/OpenSmalltalk/vm/commit/da3fafdec9444754af104e0ed9f613f6… we now have functional callbacks on all x86 platforms, ARM32 platforms and x86_64 platforms. There's a simple example Alien class>>exampleCqsort that shows how to use the system and tests the implementation using the C library's sort quick sort implementation that takes a function pointer as an argument to use for comparing pairs of elements. This is mapped onto a Smalltalk block by Alien's callback implementation. The example sorts 100 random double-precision floats using qsort and a callback into Smalltalk. _,,,^..^,,,_ best, Eliot

June 23, 2016

Re: [Pharo-dev] <primitive: 79 error: ec> question

by Eliot Miranda

> On Jun 22, 2016, at 8:25 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > It's a special case added a couple year ago to figure out why a primitive fail. That's right. It was an exception to the rule in VisualWorks and its convenience is so strong I brought it over. But the Squeak/Pharo code dates back to 2008 when I added this in Newspeak, which runs on Squeak. > It's a special temporary variable that holds an error code. The special object array defines a list of error code that the VM can use to explain to the programmer why the primitive failed, which are currently symbols. Right. In the VM primitive failure is indicated by a variable called primFailCode being non-zero. On activating a method with a failing primitive, if the index is in bounds of the primitiveFailCodes array in the specialObjectsArray then the failure code substitutes the symbol in the primitiveFailCodes array, otherwise it supplies the integer value. This is simpler than the VW scheme which allocates a PrimFailCode that has a name inst car and a parameter. Our system has only the name. > >> On Wed, Jun 22, 2016 at 4:22 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >> > On 22 Jun 2016, at 15:59, stepharo <stepharo(a)free.fr> wrote: >> > >> > Hi >> > >> > I want to explain where ec is coming. >> > >> > I thought that the arguments of pragmas could only be literal and when I see ec it looks like a variable set by the VM >> > >> > >> > newMethod: numberOfBytes header: headerWord >> > "Primitive. Answer an instance of me. The number of literals (and other >> > information) is specified by the headerWord (see my class comment). >> > The first argument specifies the number of fields for bytecodes in the >> > method. Fail if either argument is not a SmallInteger, or if numberOfBytes >> > is negative, or if memory is low. Once the header of a method is set by >> > this primitive, it cannot be changed to change the number of literals. >> > Essential. See Object documentation whatIsAPrimitive." >> > >> > <primitive: 79 error: ec> >> > ec == #'insufficient object memory' ifTrue: >> > [^self handleFailingNewMethod: numberOfBytes header: headerWord]. >> > ^self primitiveFailed >> > >> > >> > Stef >> > >> > >> >> That is correct. Itâs still a literal though. >

June 22, 2016

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

by Alexandre Bergel

Thanks for this report! I also experience crashes, that are hard to reproduce. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jun 22, 2016, at 1:18 PM, J.F. Rick <self(a)je77.com> wrote: > > Here's some more information on this: When I was having this issue, Pharo was pretty unstable. It would crash regularly when using AthensCairoSurface. It would also sometimes have weird visual artifacts. I'm not sure what these were but it almost looked like the bits were shifted so that rgb turned into gbr or something. Anyway, I've gone ahead and dumped that image, loaded all the same code, and started making sure that I don't save the image when testing the code. I haven't had a crash since. Perhaps that gives a clue about what was going on. > > Cheers, > > Jeff > > PS This is on the Ubuntu16 and Pharo5. > > On Sat, Jun 18, 2016 at 12:36 PM J.F. Rick <self(a)je77.com <mailto:self@je77.com>> wrote: > I'm using Athens rendering for my multi-touch applications on Pharo5. As part of that, I create a surface: > surface := AthensCairoSurface extent: bounds extent asIntegerPoint. > > Though the object creating that surface is deleted, the surface sticks around. So, each time I run the app, I get another instance of AthensCairoSurface hanging around. That means all the forms stick around as well. So my image can quickly grow towards the 1GB size. > > Is there anything I can do about that? Can I manually get the surface to delete itself? > > Cheers, > > Jeff

June 22, 2016

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

by J.F. Rick

Here's some more information on this: When I was having this issue, Pharo was pretty unstable. It would crash regularly when using AthensCairoSurface. It would also sometimes have weird visual artifacts. I'm not sure what these were but it almost looked like the bits were shifted so that rgb turned into gbr or something. Anyway, I've gone ahead and dumped that image, loaded all the same code, and started making sure that I don't save the image when testing the code. I haven't had a crash since. Perhaps that gives a clue about what was going on. Cheers, Jeff PS This is on the Ubuntu16 and Pharo5. On Sat, Jun 18, 2016 at 12:36 PM J.F. Rick <self(a)je77.com> wrote: > I'm using Athens rendering for my multi-touch applications on Pharo5. As > part of that, I create a surface: > surface := AthensCairoSurface extent: bounds extent asIntegerPoint. > > Though the object creating that surface is deleted, the surface sticks > around. So, each time I run the app, I get another instance of > AthensCairoSurface hanging around. That means all the forms stick around as > well. So my image can quickly grow towards the 1GB size. > > Is there anything I can do about that? Can I manually get the surface to > delete itself? > > Cheers, > > Jeff >

June 22, 2016

Re: [Pharo-dev] <primitive: 79 error: ec> question

by ClÃ©ment Bera

It's a special case added a couple year ago to figure out why a primitive fail. It's a special temporary variable that holds an error code. The special object array defines a list of error code that the VM can use to explain to the programmer why the primitive failed, which are currently symbols. On Wed, Jun 22, 2016 at 4:22 PM, Max Leske <maxleske(a)gmail.com> wrote: > > > On 22 Jun 2016, at 15:59, stepharo <stepharo(a)free.fr> wrote: > > > > Hi > > > > I want to explain where ec is coming. > > > > I thought that the arguments of pragmas could only be literal and when I > see ec it looks like a variable set by the VM > > > > > > newMethod: numberOfBytes header: headerWord > > "Primitive. Answer an instance of me. The number of literals (and > other > > information) is specified by the headerWord (see my class comment). > > The first argument specifies the number of fields for bytecodes in > the > > method. Fail if either argument is not a SmallInteger, or if > numberOfBytes > > is negative, or if memory is low. Once the header of a method is set > by > > this primitive, it cannot be changed to change the number of > literals. > > Essential. See Object documentation whatIsAPrimitive." > > > > <primitive: 79 error: ec> > > ec == #'insufficient object memory' ifTrue: > > [^self handleFailingNewMethod: numberOfBytes header: headerWord]. > > ^self primitiveFailed > > > > > > Stef > > > > > > That is correct. Itâs still a literal though. >

June 22, 2016

Re: [Pharo-dev] senders seems broken

by Nicolai Hess

broken, or a deprecation warning 2016-06-22 16:14 GMT+02:00 stepharo <stepharo(a)free.fr>: > Ok > > I'm in the train so I will not try to download it :) > > The finder is broken. We cannot use the dropdown. > > Do you know if it was fixed too. > > > Setf > > > Le 22/6/16 Ã 16:02, Marcus Denker a Ã©crit : > > There where bugs but they should be fixed in the latest version. >> >> (in 60105 it works for me again). >> >> On 22 Jun 2016, at 15:53, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi marcus >>> >>> can you browse senders? Because I cannot anymore. >>> >>> Stef >>> >>> >>> >> >> > >

June 22, 2016

Re: [Pharo-dev] <primitive: 79 error: ec> question

by Max Leske

> On 22 Jun 2016, at 15:59, stepharo <stepharo(a)free.fr> wrote: > > Hi > > I want to explain where ec is coming. > > I thought that the arguments of pragmas could only be literal and when I see ec it looks like a variable set by the VM > > > newMethod: numberOfBytes header: headerWord > "Primitive. Answer an instance of me. The number of literals (and other > information) is specified by the headerWord (see my class comment). > The first argument specifies the number of fields for bytecodes in the > method. Fail if either argument is not a SmallInteger, or if numberOfBytes > is negative, or if memory is low. Once the header of a method is set by > this primitive, it cannot be changed to change the number of literals. > Essential. See Object documentation whatIsAPrimitive." > > <primitive: 79 error: ec> > ec == #'insufficient object memory' ifTrue: > [^self handleFailingNewMethod: numberOfBytes header: headerWord]. > ^self primitiveFailed > > > Stef > > That is correct. Itâs still a literal though.

June 22, 2016

Re: [Pharo-dev] shit + double click on a category :)

by Mariano Martinez Peck

Cool! I didn't know about it :) On Wed, Jun 22, 2016 at 10:54 AM, stepharo <stepharo(a)free.fr> wrote: > We should call a method rename and class rename refactoring for classes > and methods and it will be gorgeous :) > > yes it is shift :) > > > Setf > > Le 22/6/16 Ã 11:50, Denis Kudriashov a Ã©crit : > > Really nice. And I found that double click on method opens new browser on > it. > > 2016-06-22 11:44 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi guys >> >> alain showed me that click + double click on a category is really nice to >> rename a category. >> >> May be you knew it but this is nice. >> >> >> Stef >> >> >> > > -- Mariano http://marianopeck.wordpress.com

June 22, 2016

Re: [Pharo-dev] senders seems broken

by stepharo

Ok I'm in the train so I will not try to download it :) The finder is broken. We cannot use the dropdown. Do you know if it was fixed too. Setf Le 22/6/16 Ã 16:02, Marcus Denker a Ã©crit : > There where bugs but they should be fixed in the latest version. > > (in 60105 it works for me again). > >> On 22 Jun 2016, at 15:53, stepharo <stepharo(a)free.fr> wrote: >> >> Hi marcus >> >> can you browse senders? Because I cannot anymore. >> >> Stef >> >> > >

June 22, 2016

[pharo-project/pharo-core] fbf352: 60107

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: fbf3521210b17541b348788746be6210e0d3fb40 https://github.com/pharo-project/pharo-core/commit/fbf3521210b17541b3487887… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-22 (Wed, 22 Jun 2016) Changed paths: A Deprecated60.package/extension/Integer/instance/asBytesDescription.st R Files.package/extension/Integer/instance/asBytesDescription.st A Keymapping-Core.package/extension/DialogWindow/instance/closeWindowAction.st M Keymapping-Core.package/extension/SystemWindow/class/buildShortcutsOn_.st A Keymapping-Core.package/extension/SystemWindow/instance/closeWindowAction.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60106.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60107.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60106.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60107.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/text selection/autoSelect_.st M Zinc-HTTP.package/ZnUtils.class/class/streaming/signalProgress_total_.st Log Message: ----------- 60107 18557 DialogWindow: close window should act as "Cancel" https://pharo.fogbugz.com/f/cases/18557 18565 sendersOf autoselect selects wrong interval https://pharo.fogbugz.com/f/cases/18565 18254 Strange results of Integer>>#asBytesDescription https://pharo.fogbugz.com/f/cases/18254 http://files.pharo.org/image/60/60107.zip

June 22, 2016