May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Roassal Camp Smalltalk, July 12

by Alexandre Bergel

>> If you wish to participate, get in touch with us. Since we will probably >> have a sponsoring of the event, it would be nice to know how many will >> attend to ease the logistic and the pizza ordering :-) > > What do you use as a global pizza delivery service? > Or where (timezone) did you plan to do this? At ESUG :-) Alexandre

May 8, 2015

Problem using Zinc in Pharo 4 (Moose 5.1)

by PBKResearch

Hello I have been trying to use Soup class>> fromUrl: to access the contents of a web page. It halts with a message from Zinc about malformed UTF-8. The page displays perfectly in Firefox, so I copied the page source from there to a local file and tried to read it from there. Again a message from Zinc: 'Invalid utf8 input detected'. It's strange, because the page is not in UTF-8. The head contains: <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">. I have tried to find how to specify the character set in reading files with Zinc, but without success.* If it's relevant, I am using Pharo4.0 Latest update: #40613, downloaded two days ago. The address of the web page is: http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109 <http://kompakt.handelsblatt-service.com/ff/display.php?msgID=725164109&adr= peter(a)pbkresearch.co.uk> &adr=peter(a)pbkresearch.co.uk. Other pages from the same source are loaded and analysed with no problem. Processing this page seems to go off course as soon as it encounters the character code 246, which is a correct o-umlaut in ISO-8859-1. Any advice gratefully received. Peter Kenny *I would be happy with advice to RTFM, if someone would point out the relevant bit of the FM.

May 8, 2015

Re: [Pharo-users] Roassal Camp Smalltalk, July 12

by Offray Vladimir Luna CÃ¡rdenas

Hi, Really good news! More comments inline. El 07/05/15 a las 09:48, Alexandre Bergel escribiÃ³: > Dear Colleagues and Friends, > > We are happy to announce we will organize a CampSmalltalk about the Roassal > visualization engine, on _Sunday 12 July_. > > As far as we have seen, the interests are multiple. Here is a list of topics we > will happy to work on: > - Improving Grapher, our charting library > - Fixing bugs, addressing recently uncovered issues (e.g., composite shapes) > - HTML/JavaScript export > > Some participants have indicated a great interest in: > - Port of Roassal on VisualWorks > - Using Roassal on Gemstone > I would add some interests like using Roassal to build data narratives (see some examples at [1]) and the integration to end user "apps" (grafoscopio[2]) where Roassal is a core part of the experience [1] http://mutabit.com/offray/static/blog/output/posts/visualizing-politiciansp… [2] http://mutabit.com/grafoscopio/ > If you wish to participate, get in touch with us. Since we will probably have a > sponsoring of the event, it would be nice to know how many will attend to ease > the logistic and the pizza ordering :-) > Sponsoring means having the possibility to attend to the event? I have made consistently workshops and hackathons using Roassal (we will have more all Saturdays of May and we're planning one week long workshop in June) and I think that learning from others in place could be a significant improvement in the way I can spread the knowledge and make a stronger local community in Colombia... So just showing my interest in attending to have the proper time in getting my visa ready ;-) > Cheers, > Alexandre > -- Cheers, Offray

May 8, 2015

MorphicDraw, now with Spec, Glamour & PolyMorph

by Stephan Eggermont

After starting with a PolyMorph window & toolbar, I've now added a Glamour and Spec one. Code: http://www.smalltalkhub.com/mc/StephanEggermont/MorphicDraw/main Documentation: https://github.com/StephanEggermont/MorphicDraw I find it difficult to explain the choices for event handling. I'm using both handleListenEvent: and mouseDown: and on:send:to: and haven't even started using announcements. What am I supposed to be using when, and what is supposed to be replaced in Bloc? Stephan

May 8, 2015

Re: [Pharo-users] Roassal Camp Smalltalk, July 12

by Stephan Eggermont

On 08/05/15 16:55, Serge Stinckwich wrote: > I guess this will be just before ESUG conference ;-) Uhmm, yep, that makes sense. Stephan

May 8, 2015

Re: [Pharo-users] Roassal Camp Smalltalk, July 12

by Serge Stinckwich

I guess this will be just before ESUG conference ;-) On Fri, May 8, 2015 at 1:43 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 07/05/15 16:48, Alexandre Bergel wrote: >> >> If you wish to participate, get in touch with us. Since we will probably >> have a sponsoring of the event, it would be nice to know how many will >> attend to ease the logistic and the pizza ordering :-) > > > What do you use as a global pizza delivery service? > Or where (timezone) did you plan to do this? > > Stephan > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 8, 2015

Re: [Pharo-users] New fast path for proxy loading in Voyage

by Henrik Johansen

> On 08 May 2015, at 2:12 , Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: > Hi Esteban! > As we talked about on IRC yesterday, I had hoped to employ the fast become discussed in > http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455… <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455…> > to bring faster proxy loading untill Spur arrives. > Sadly, it's not present in any current VM's, for reasons unknown*. > > Luckily, the alternative proposed by Levente in the original thread (http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370… <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370…>) is appropriate for our case. > As I don't have write-access to Voyage repo, I've attached the package with the changes (which work in both 3.0 and 4.0, but I assume not older, due to using the SlotBuilder for anon subclasses) > > > hahahahah excellent. It was similar to the same idea I have for my proxies in Marea. In my case, what I did is to have 3 types of Proxies (each with each different object "format" -> normal, compact, long), and each of those proxy classes was a "variableSubclass". So then when I received the object to proxify, I would create an instance (the correct one from one of those 3 proxy classes) of the size of the object to proxify. Therefore, both, the proxy and the target would have same size and format, and therefore I could simply apply Igor idea. Yeah, it's a really nice fast-path, when the VM's become implementation usually involves a heap scan... In the case of Voyage, we're restricted in that we don't start out with a database ID, and not the actual original object, so perfectly pre-shaping the proxy is impossible. Variably sized objects are right out, so I settled on the compromise that was easy to do; fixed size objects with equal or greater number of instvars as the proxy class. To do fast swapping with objects of less than 3 slots, the current data held in proxy slots would have to be held somewhere external, which is doable, but ugly. (You can also work around this easily if the performance hit is noticeable by adding dummy slots...) Compact proxies is a really limited use case, since you never store any of the builtin ones in buckets directly, you'd have to manually make your mapped classes compact. Seeing as how it's really just a holdover performance hack till Spur is ready for use and become: becomes fast, I don't think it makes sense implementing either in the context of Voyage. Cheers, Henry

May 8, 2015

Re: [Pharo-users] New fast path for proxy loading in Voyage

by Henrik Johansen

A few mistakes were revealed when testing using a real application; 1) I'd forgotten to hook up the classFor: method to the proxy creation methods, so it was never actually used... 2) Since copyFrom: is just a pseudo-forwardBecome:, we need to explicitly replace existing references to the value returned by selectOne: ... I hope the repository cache is the only place it is stored during selectOne:, if there are more, additional fixup post copyFrom: in becomeForwardWithSameShape: is needed. The attached version should fix the above two issues. Cheers, Henry > On 08 May 2015, at 2:09 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > cool, thanks! > copied and merged :P > > Esteban > >> On 08 May 2015, at 14:00, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >> Hi Esteban! >> As we talked about on IRC yesterday, I had hoped to employ the fast become discussed in >> http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455… <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455…> >> to bring faster proxy loading untill Spur arrives. >> Sadly, it's not present in any current VM's, for reasons unknown*. >> >> Luckily, the alternative proposed by Levente in the original thread (http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370… <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370…>) is appropriate for our case. >> As I don't have write-access to Voyage repo, I've attached the package with the changes (which work in both 3.0 and 4.0, but I assume not older, due to using the SlotBuilder for anon subclasses) >> >> The package comment contains a workspace doit for comparision, but long story short, for objects covered by the new fast path, you can now materialize more than million objects in the time it previously took to materialize five.

May 8, 2015

Re: [Pharo-users] New fast path for proxy loading in Voyage

by Mariano Martinez Peck

On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Hi Esteban! > As we talked about on IRC yesterday, I had hoped to employ the fast become > discussed in > > http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455… > to bring faster proxy loading untill Spur arrives. > Sadly, it's not present in any current VM's, for reasons unknown*. > > Luckily, the alternative proposed by Levente in the original thread ( > http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370…) > is appropriate for our case. > As I don't have write-access to Voyage repo, I've attached the package > with the changes (which work in both 3.0 and 4.0, but I assume not older, > due to using the SlotBuilder for anon subclasses) > > hahahahah excellent. It was similar to the same idea I have for my proxies in Marea. In my case, what I did is to have 3 types of Proxies (each with each different object "format" -> normal, compact, long), and each of those proxy classes was a "variableSubclass". So then when I received the object to proxify, I would create an instance (the correct one from one of those 3 proxy classes) of the size of the object to proxify. Therefore, both, the proxy and the target would have same size and format, and therefore I could simply apply Igor idea. > The package comment contains a workspace doit for comparision, but long > story short, for objects covered by the new fast path, you can now > materialize more than million objects in the time it previously took to > materialize five. > > Cheers, > Henry > > > > *Need to check we aren't becoming primitive literals before being ok to > include? Seriously? > You can do ((StandardFileStream >> #primRead:into:startingAt:count:) > literalAt: 1) at: 4 put: 34 to achieve the same that become apparently must > at all costs guard against, does that mean we should also introduce the > same kind of primitive fail check requirements to at:put:? > I get that there are some objects you really don't want to become: due to > VM linking them internally in various ways, but checks that apply to > *certain instances* of a class, should be unneccessary, imho (or, better, > done at the user site) > > -- Mariano http://marianopeck.wordpress.com

May 8, 2015

Re: [Pharo-users] New fast path for proxy loading in Voyage

by Esteban Lorenzano

cool, thanks! copied and merged :P Esteban > On 08 May 2015, at 14:00, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Hi Esteban! > As we talked about on IRC yesterday, I had hoped to employ the fast become discussed in > http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455… <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td43455…> > to bring faster proxy loading untill Spur arrives. > Sadly, it's not present in any current VM's, for reasons unknown*. > > Luckily, the alternative proposed by Levente in the original thread (http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370… <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp370…>) is appropriate for our case. > As I don't have write-access to Voyage repo, I've attached the package with the changes (which work in both 3.0 and 4.0, but I assume not older, due to using the SlotBuilder for anon subclasses) > > The package comment contains a workspace doit for comparision, but long story short, for objects covered by the new fast path, you can now materialize more than million objects in the time it previously took to materialize five. > > Cheers, > Henry > <Voyage-Mongo-Core-HenrikSperreJohansen.55.mcz> > > > *Need to check we aren't becoming primitive literals before being ok to include? Seriously? > You can do ((StandardFileStream >> #primRead:into:startingAt:count:) literalAt: 1) at: 4 put: 34 to achieve the same that become apparently must at all costs guard against, does that mean we should also introduce the same kind of primitive fail check requirements to at:put:? > I get that there are some objects you really don't want to become: due to VM linking them internally in various ways, but checks that apply to *certain instances* of a class, should be unneccessary, imho (or, better, done at the user site)

May 8, 2015