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

Re: [Pharo-dev] vested interest in PharoJS?

by phil＠highoctane.be

I want it for bridging Pharo with a browser running aframe.io VR stuff. So that I can render VR scenes and drive them from Pharo. A Seaside aframe.io set of brushes is somewhat underway here. I go to a VR meetup end of the month, so progress should happen by then. Phil On Wed, Jun 14, 2017 at 11:46 AM, Siemen Baader <siemenbaader(a)gmail.com> wrote: > Hi all, > > Is anyone else interested in PharoJS and making it mature for their own > commercial mobile and single page web app (and node.js) development? > > I think it has a huge potential because it brings the browser runtime and > many libraries and online services from the JS world to us Smalltalkers > while letting us keep our agile development and good CS practices. But it > does not yet have the necessary features and documentation to work smoothly. > > -- Siemen >

June 14, 2017

Re: [Pharo-dev] I want to get in contact with raphael luque from madrid :)

by Serge Stinckwich

Maybe you can try to contact him on Twitter: https://twitter.com/rafael_luque On Wed, Jun 14, 2017 at 1:11 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guys. > > I tried to get in contact with raphael but my emails do not seem to go > to destination. > Do you have the email of raph/fael luque from madrid? > > Stef > -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 14, 2017

Re: [Pharo-dev] Pharo6 deployment issues

by Marcus Denker

>>> >> >> Yes! For the Deprecation one I can prepare the fixes for Pharo6 and 7. The other I have no idea yet, but having it on the tracker would be good. >> > > I added > https://pharo.fogbugz.com/f/cases/20148/transforming-deprecations-should-ta… <https://pharo.fogbugz.com/f/cases/20148/transforming-deprecations-should-ta…> This is now in update 60601, the issue has ben moved to Pharo7 to be integrated there later, too Marcus

June 14, 2017

[pharo-project/pharo-core] 89d297: 60501

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 89d297dce3beea42497ef1b7aea3d7460bc75a4b https://github.com/pharo-project/pharo-core/commit/89d297dce3beea42497ef1b7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-14 (Wed, 14 Jun 2017) Changed paths: M Kernel.package/Deprecation.class/class/class initialization/initialize.st M Kernel.package/Deprecation.class/class/logging/deprecationsWhile_.st M Kernel.package/Deprecation.class/class/settings/raiseWarning.st M Kernel.package/Deprecation.class/class/settings/showWarning.st M Kernel.package/Deprecation.class/instance/handling/transform.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60500.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60501.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60500.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60501.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/VersionBrowser.class/instance/accessing/displayStringsFor_.st Log Message: ----------- 60501 20093 Missing source stamp makes changes hard to view https://pharo.fogbugz.com/f/cases/20093 20148 transforming deprecations should take #showWarning into account https://pharo.fogbugz.com/f/cases/20148 http://files.pharo.org/image/60/60501.zip

June 14, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60501 Home: https://github.com/pharo-project/pharo-core

June 14, 2017

Re: [Pharo-dev] [Vm-dev] BUG? A problem with callbacks that shows up in 64bits (but is on 32bits too)

by Stephane Ducasse

Hi igor but this is also important that if the user is a nice guy and the library is acting well we do not have to write a plugin for each callback, no? To me forcing people to write a plugin is not nice. Having solution that would work on normal use case is really nice to have. Stef On Thu, Mar 16, 2017 at 12:04 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 16 March 2017 at 01:44, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> Hi Igor, >> >> On Wed, Mar 15, 2017 at 2:53 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> >>> Here's my d) >>> implement callback functions in C, or in native form => no need for >>> entering the smalltalk execution => no risk of GC => nothing to worry about. >>> >>> I guess nobody will like it (and will be right, of course ;) , but it is >>> how it was originally done. I used NativeBoost to implement those callback >>> functions and they're won't cause any GC problems. >> >> >> yes, I like this. I was wondering why the callbacks solution was used at >> all yesterday. All they do is redirect to the cairo library. What are the >> reasons? Tedious to write and maintain the necessary simple plugin? >> >> ClÃ©ment pointed out a really ugly problem with the current implementation. >> If one calls back into Pharo from the BitBlt primitives and then reinvokes >> BitBlt, say by innocently putting a halt in those callbacks, then the >> original BitBlt's state will get overwritten by the BitBlt invocations in >> the callback's dynamic exert. At least with my changes the BitBlt primitive >> will abort, rather than continue with the invalid state. >> >>> >>> That, of course, gave me solution in this concrete case, but not in >>> general.. i.e. : if you have another callback that cannot be implemented >>> na(t)ively, then >>> you facing similar problems, mainly: how to work around the problem, that >>> primitive(s) that using callbacks may capture state, that are subject of GC >>> activity. >>> >>> In general , then, i think such primitive should be (re)written in such >>> way , that it won't get puzzled by GC.. and addGCRoot(s), IMO then best way, >>> from general interfacing/implementation standpoint. >>> I would just add extra interface for using it especially in primitives, >>> so that it >>> 1) won't punish primitive writer with too much coding >>> 2) automatically handle primitive/callback nesting e.g. >>> primitive1 -> adds roots1 -> calls fn -> callback -> st code -> >>> primitive2 -> adds roots2 -> calls fn2 -> callback2 ... >>> >>> >>> something like this: >>> >>> static initialized once myprimooptable = [ a,b,c]. >>> vm pushPrimRoots: myooptable. >>> self do things primitive does. >>> vm popPrimRoots >>> >>> or, since we have green threading, then maybe better will be in this >>> form: >>> >>> rootsId := static initialized once myprimooptable = [ a,b,c]. >>> vm pushPrimRoots: myooptable. >>> self do things primitive does. >>> vm popPrimRoots: rootsId. >> >> >> We kind of have this with the addGCRoot: interface. But I think it's much >> better to design the system so that the primitive fails and can be retried. >> The problem there is having to have the primitive failure code check and >> roll back. For example in the copyBits primitive one sees >> >> ((sourceForm isForm) and: [sourceForm unhibernate]) >> ifTrue: [^ self copyBits]. >> ((destForm isForm) and: [destForm unhibernate]) >> ifTrue: [^ self copyBits]. >> ((halftoneForm isForm) and: [halftoneForm unhibernate]) >> ifTrue: [^ self copyBits]. >> >> This is really scruffy because...GrafPort implements copyBits, so this >> ends up not just retrying the primitive but running a lot more besides. One >> way to write it is >> >> >> ((sourceForm isForm) and: [sourceForm unhibernate]) >> ifTrue: [^ self perform: #copyBits withArguments: #() inSuperclass: >> BitBlt]. >> ((destForm isForm) and: [destForm unhibernate]) >> ifTrue: [^ self perform: #copyBits withArguments: #() inSuperclass: >> thisContext method methodClass]. >> ((halftoneForm isForm) and: [halftoneForm unhibernate]) >> ifTrue: [^ self perform: #copyBits withArguments: #() inSuperclass: >> thisContext methodClass]. >> >> but that's ugly. >> >> A mechanism that was in the VM would be nice. The state for the >> invocation is saved on the stack. So there could be a special failure path >> for this kind of recursive invocation problem; another send-back such as >> doesNotUnderstand: attemptToReturn:through:. Note (I'm sure you know this >> Igor) that there are primitives such as the ThreadedFFIPlugin's call-out >> primitive that very much expect to be invoked recursively and have no >> problem with it. >> > > Yes, i know it. But keep in mind, that reentrant FFI callout mechanism means > *just* reentrant FFI callout code, it doesn't means that things, it will be > calling, automagically become reentrant as well. > And the above note about "ClÃ©ment pointed out a really ugly problem" is good > example of it :) > And since you cannot predict/prevent/pretend/protect every single piece of > code, that FFI users are going to call, there's no solution to that, unless > users understand what they do and be aware of pitfalls and consequences. > > It is quite easy to say "meh.. your FFI don't works.. go away, come year > later.. i will use other (put other language/software system there)".. > mostly because of ignorance, that there's a limits on what FFI can do and > what can't. > > -- > Best regards, > Igor Stasenko.

June 14, 2017

Re: [Pharo-dev] Big Pharo 6 Image (32 bit) crashes while garbage collecting

by Cyrille Delaunay

This is on Mac OS Sierra (Version 10.12.1). I did not try yet with 64 bit, but I will ! 2017-06-14 14:13 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Cyril > did you try the 64 bits? > Because the 32 bits is not made for 1Gb image > Stef > > On Wed, Jun 14, 2017 at 2:12 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > Tx cyril > > Which os? Mac? > > > > On Wed, Jun 14, 2017 at 12:43 PM, Cyrille Delaunay > > <cy.delaunay(a)gmail.com> wrote: > >> Hello, > >> > >> I am running a Pharo 6 32 bit image (Pharo 6.0 > >> Latest update: #60499). > >> I saved this image after loading big data in memory (image is 995 MB). > >> After saving, the image became "unstable", and always crashed after > doing > >> some random actions. > >> I tries to open the image and perform: Smalltalk garbageCollect. > >> The image systematically crashes. > >> I Join the dump files I have been able to collect. > >> > >> > >> > >> -- > >> Cyrille Delaunay > > -- Cyrille Delaunay

June 14, 2017

Re: [Pharo-dev] Pharo6 deployment issues

by Stephane Ducasse

Thanks bug entry are important! Let us continue to improve our lovely system On Wed, Jun 14, 2017 at 10:18 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 14 Jun 2017, at 09:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 13 Jun 2017, at 13:44, Holger Freyther <holger(a)freyther.de> wrote: >>> >>> Hi! >>> >>> today I started to look at of why my benchmark in the CI stalled/didn't complete and I see three separate issues and wonder how to address them properly? I have a truncated log attached >>> >>> >>> Issues: >>> * In my CI script I disable Deprecation warnings but this has no influence on Deprecation>>#transform. This means that it will try to write the changes?! To scale we start the same image multiple times. >>> >>> * Somehow writing the log fails (and the TCP connection fails the same time?!) with a primitive error. >>> >>> * Errors "recurse". So while we try to exit the image it seems to fail the same way and tries again.. which fails again.. which fails again..at some point no new context will be allocated. >>> >>> >>> Solutions? >>> >>> * Prevent new errors in NonInteractiveUIManager>>#unhandledErrorDefaultAction:? >>> >>> * Check in >>#transform if transformation is disabled and then return early? >>> >> >> yes! This should have been like that. >> >>> * ??? No idea.. I will strace to see what happens to the Debug log.. but ideally I would like this file writing to be disabled. :) >>> >>> >>> Should I create tickets? >>> >> >> Yes! For the Deprecation one I can prepare the fixes for Pharo6 and 7. The other I have no idea yet, but having it on the tracker would be good. >> > > I added > https://pharo.fogbugz.com/f/cases/20148/transforming-deprecations-should-ta…

June 14, 2017

Re: [Pharo-dev] Big Pharo 6 Image (32 bit) crashes while garbage collecting

by Stephane Ducasse

Cyril did you try the 64 bits? Because the 32 bits is not made for 1Gb image Stef On Wed, Jun 14, 2017 at 2:12 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Tx cyril > Which os? Mac? > > On Wed, Jun 14, 2017 at 12:43 PM, Cyrille Delaunay > <cy.delaunay(a)gmail.com> wrote: >> Hello, >> >> I am running a Pharo 6 32 bit image (Pharo 6.0 >> Latest update: #60499). >> I saved this image after loading big data in memory (image is 995 MB). >> After saving, the image became "unstable", and always crashed after doing >> some random actions. >> I tries to open the image and perform: Smalltalk garbageCollect. >> The image systematically crashes. >> I Join the dump files I have been able to collect. >> >> >> >> -- >> Cyrille Delaunay

June 14, 2017

Re: [Pharo-dev] Big Pharo 6 Image (32 bit) crashes while garbage collecting

by Stephane Ducasse

Tx cyril Which os? Mac? On Wed, Jun 14, 2017 at 12:43 PM, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: > Hello, > > I am running a Pharo 6 32 bit image (Pharo 6.0 > Latest update: #60499). > I saved this image after loading big data in memory (image is 995 MB). > After saving, the image became "unstable", and always crashed after doing > some random actions. > I tries to open the image and perform: Smalltalk garbageCollect. > The image systematically crashes. > I Join the dump files I have been able to collect. > > > > -- > Cyrille Delaunay

June 14, 2017