January 2014 - Pharo-dev - lists.pharo.org

errorImproperStore error because of change in GRPharoPlatform>>readWriteByteStream

by Sabine KnÃ¶fel

Hi, I am migrating from Pharo 2.0 to Pharo3.0 My updateRoot contains the following statement: updateRoot: aHtmlRoot aHtmlRoot link url: RKALibrary / #mainStylesLess; relationship: 'stylesheet/less'; beCss. In Pharo 3.0 I get ByteArray errorImproperStore error (Pharo2.0 works) When debugging into, I see: In Pharo 2.0 GRPharoPlatform>>readWriteByteStream "ByteArray based read write stream" ^ RWBinaryOrTextStream on: (ByteArray new: 4096) In Pharo 3.0 GRPharoPlatform>>readWriteByteStream "ByteArray based read write stream" ^ ReadWriteStream on: (ByteArray new: 4096) This is the reason for the error improperStore error. If I change from ReadWriteStream to RWBinaryOrTextStream, it works. Can anyone fix this or is my conclusion wrong? Regards Sabine -- View this message in context: http://forum.world.st/errorImproperStore-error-because-of-change-in-GRPharo… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 16, 2014

Re: [Pharo-dev] [HELP] Phratch translation

by btc＠openinworld.com

jannik.laval wrote: > Dear smalltalkers, phratchers and everybody interested to help Phratch development. > We need you as an international community. Phratch needs your help to be multilingual. > > The most of work is already done, It is based on the Scratch work (Thank you for all the supported languages). Now, as Phratch has a lot of new features, we need to translate each of these new features. > > For each of the following languages (ar, bg, ca, cs, da, de, el, es, et, eu, fa, fi, fr_CA, gl, he, hr, ht, hu, id, is, it, ja_hira, ja, kn, ko, lt, mk, mn, mr, ms, ne, nl, no, pl, pt_br, pt, ro, ru, rw, sk, sl, sv, th, tr, uk, vi, zh_cn, zh_tw), we need to complete the lines available in the phratch issue tracker (https://code.google.com/p/phratch/issues/detail?id=120) You can post your work as a comment or send me a mail, I will then integrate it in Phratch. > > For each expression there is a msgid in english, that should not be changed. Then, there is a msgstr that should be complete in the specific language. All elements in the $$ (like $Number$) are variables, they should not be changed but they have to be integrated in your translation. For example, in french: > === > msgid "replace costume $Number$ with $NewCostume$" > msgstr "remplacer le costume $Number$ avec $NewCostume$" > === > > There is less than 130 small expressions. It is 1 or 2 hours of work, and it helps us a lot. > > Thank you for your help. > Cheers, > Jannik > > Transifex provide a free "continuous localization" translation service for open source projects. https://www.transifex.com/ Disclaimer: I haven't used them yet. Its just seems good. cheers -ben

Jan. 16, 2014

Re: [Pharo-dev] IncompatibleLayoutConflict with NativeBoost in recent #30700

by Marcus Denker

Hello, I was looking into that, the first (maybe only) reason is that the new class builder can not make anonymous subclasses of classes with ByteLayout https://pharo.fogbugz.com/f/cases/12488/Can-not-create-newAnonymousSubclass… On 16 Jan 2014, at 16:55, Torsten Bergmann <astares(a)gmx.de> wrote: > When loading PunQLite [1] in recent Pharo3.0 Latest update: #30700 > I get an exception (IncompatibleLayoutConflict). > > It all boils down to the single expression: > > (NBExternalTypeValue ofType: 'NBInt64') > > from an initialize method which raises this. When I try in Pharo3.0 Latest > update: #30579 it works. > > How can this be fixed? Is there something missing from the latest NB integration? > > Thx > T. > > > [1] http://smalltalkhub.com/#!/~MasashiUmezawa/PunQLite >

Jan. 16, 2014

IncompatibleLayoutConflict with NativeBoost in recent #30700

by Torsten Bergmann

When loading PunQLite [1] in recent Pharo3.0 Latest update: #30700 I get an exception (IncompatibleLayoutConflict). It all boils down to the single expression: (NBExternalTypeValue ofType: 'NBInt64') from an initialize method which raises this. When I try in Pharo3.0 Latest update: #30579 it works. How can this be fixed? Is there something missing from the latest NB integration? Thx T. [1] http://smalltalkhub.com/#!/~MasashiUmezawa/PunQLite

Jan. 16, 2014

Re: [Pharo-dev] Pharo on a Raspbian

by Marcus Denker

On 16 Jan 2014, at 16:10, jannik laval <jannik.laval(a)gmail.com> wrote: > Dear pharoers, > > I tried to load a Pharo 2.0 on a Raspbian (with Phratch inside !). > It works fine (the VM Squeak is already included in the Raspbian). > > I tried it with Pharo3.0 and it does not work. What changed in Pharo3.0 ? > There is this: https://pharo.fogbugz.com/f/cases/11869/NativeBoost-usage-in-PreferenceStar…

Jan. 16, 2014

Pharo on a Raspbian

by jannik laval

Dear pharoers, I tried to load a Pharo 2.0 on a Raspbian (with Phratch inside !). It works fine (the VM Squeak is already included in the Raspbian). I tried it with Pharo3.0 and it does not work. What changed in Pharo3.0 ? I know that some guys work on a PharoVM on a Raspbian. What is the status ? Thank you all. -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

Jan. 16, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by ClÃ©ment Bera

Hi Doru, I agree that custom tools are valuables. I don't know anyone working in VMs that does not have his own tools. Have you ever looked at the StackVM / CogVM Simulator ? They're cool and similar to what I am doing for my research project. I believe Eliot showed it in some presentation. And see how the java Maxine VM guys sold their inspector tool suite. For the roassal visualization, take the image there: https://ci.inria.fr/rmod/view/Mate/job/Sista/ and execute: (Morph>>#invalidRect:from:) liliCFG convertToSSA roassalVisualisation This should work on any method. The alternative, the text visualization that I used before, is: (Morph>>#invalidRect:from:) liliCFG convertToSSA printString. As you can see in complex control flow the roassal visualization is way better. For the 3 other tools I did/am doing the problem is that the other project is not stable currently. It will be stable again in several months. I have one half- stable image for demo, but even there only the Memory inspector works (the stack inspector is not stable). It requires to bootstrap an image in a byte array, the bootstrapped image being in a different object's format. So I guess I could show you some tools this summer (or this autumn) if you are really interested but not now. Basically there's an inspector for the objects in memory, for the stack, and some kind of cpu instructions debugger. Note that the problem is not in writing tools itself but in building a running system where I could apply the tools. Another interesting tool suite is the one from spoon: 3D visu: http://www.youtube.com/watch?v=FQgMlpQpu7w 2D visu: http://www.youtube.com/watch?v=1Uh8v7IzXJk The first tool would be cool as an alternative to the pointer explorer to detect memory leaks. Cheers, 2014/1/16 Tudor Girba <tudor(a)tudorgirba.com> > Hi Clement, > > I am happy you see value in these specific tools and that you built your > own. I strongly believe there is great potential for Pharo in showing how > development can change dramatically when these custom tools become cheap, > and I would want to collect examples that provide incentives for others to > do the same. So now, I am even more interested in taking a look :) > > Could you point me to: > - the way to setup the image (ideally with scripts starting from a Pharo > 3.0 image) > - the Spec tools and Roassal visualizations you built > - some instances of how to trigger the inspectors and visualizations > > ? > > Cheers, > Doru > > > On Wed, Jan 15, 2014 at 9:45 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > >> Hello, >> >> I looked in the literature and there are a few paper about exactly the >> visualization I want. >> Examples: >> a paper about Graph Layout for Code Flow Visualization >> >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.3748&rep=rep1&… >> a bachelor thesis on java control flow graph visualization for compiler >> optimization >> http://ssw.jku.at/General/Staff/TW/Wuerthinger06Bachelor.pdf >> >> Perhaps at some point if we find a bachelor to hire in our team we could >> ask him to implement such a visualization too (as they did for java >> seemingly). >> >> But I looked at java's control flow graph I saw they would not increase >> much my productivity compared to what I have now, back jumps are displayed >> but not in a so good way. Therefore I'll use what I have now. However it >> would be nice to have that to teach easily compiler optimizations to people. >> >> Doru, >> >> I *really* need dedicated tools but I have already built them myself. A >> year ago, I didn't know about GTInspector and Moldable debugger, so I built >> dedicated inspectors with the old inspector framework of Pharo, then as it >> was not good enough I built new inspectors based on Spec, and I ported the >> generic classes of these inspectors in Pharo 3. Specific subclasses of >> these inspectors exist for my projects. For example, here's an inspector of >> an object in memory (an object oriented pointer): >> >> [image: Images intÃ©grÃ©es 1] >> >> With on the left the current address in memory, then what field it is for >> the object (which is the class MethodDictionary), then the address written >> at this memory location, and the result of #printString sent to this new >> address. >> >> The next tool I'm going to built is a read only debugger (I mean without >> on the fly method edition) to step on x86 disassembled instructions and its >> abstract representation (similar to R*egister Transfer Language >> <http://fr.wikipedia.org/wiki/Register_Transfer_Language>)* I used in my >> compilation chain. I discussed once with Andrei and it seems the moldable >> debugger fits more in the case where you need to debug smalltalk code or at >> least byte code dependent code. In my case I compile from AST to x86 >> skipping the byte code so as far as I know it is quite hard to build a tool >> with what you have. In addition, I'd like to plug the Spec inspectors I >> built before, which may not be easy if I choose to build the additional >> tools in Glamour. So the timing is not very good for tools in my projects. >> >> Thanks for offering your help anyway. >> >> >> However the tool you showed on RB AST is really cool, especially that I >> use all the time intermediate representations that could perfectly fit this >> kind of inspectors (mostly graphs). But I prefer visualization like the one >> of roassal. >> >> Regards >> >> >> >> >> 2014/1/15 Marcus Denker <marcus.denker(a)inria.fr> >> >>> >>> On 14 Jan 2014, at 22:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> > >>> > As far as I can see, the visualization is derived from source code. >>> This can be seen as being similar to how an AST is derived from source >>> code. The GTInspector already provides an implementation of understanding >>> this mapping. For example, in an image with GTInspector (just download the >>> Moose one for quick tests) do: >>> > (Collection>>#collect:) parseTree inspect >>> > >>> > and you get a picture like the attached one. >>> > <Inspector on a RBMethodNode (coll...ion).png> >>> >>> This is *very* impressiveâ¦ :-) >>> >>> Marcus >>> >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Jan. 16, 2014

ScreencastMorph

by DeNigris Sean

I'm working on a ScreencastMorph. The idea is to have something like what HandMorphForReplay does, but in a self contained window. The effect would be that there was another World running in a window, where the HandMorphForReplay could carry out a UI script that could be played, sped up, slowed down, rewound - all the actions you would except from a media player. Unfortunately, starting a World in a window does not seem easy. Most of the time I try it or manually mess with HandMorphs, my image locks up permanently. I've also had trouble getting the tool to resize. I tried Window -> TransformationMorph -> PasteUpMorph -> MyCoolToolWindow. That seems promising - although I have to open the tool in the world before embedding in the PasteUpMorph. The tool will resize and even interact for a while, but eventually that too seems to lock up the image. Any ideas? Thanks, Sean p.s. cross-posting to Squeak-dev and Pharo-dev. If I get it working, I plan on porting to both. p.p.s. I'm posting to the dev lists because I see clear killer uses for this in the Core system (UI Testing, live documentation)

Jan. 16, 2014

Re: [Pharo-dev] dependency of Roassal 2 visualized

by Tudor Girba

Nice! Doru On Thu, Jan 16, 2014 at 1:36 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Hi! > > Just to share the result of a small experiment we did: > > https://www.facebook.com/photo.php?fbid=573528489400419&set=a.5735284794004… > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 16, 2014

Fwd: Voyage backends

by Esteban Lorenzano

forward to list, so discussion is not lost (my fault, I bad replied in the first instance :) ) Begin forwarded message: > From: "Torsten Bergmann" <astares(a)gmx.de> > Subject: Aw: Re: Voyage backends > Date: 16 Jan 2014 14:16:12 GMT+1 > To: "Esteban Lorenzano" <estebanlm(a)gmail.com> > > Hi Esteban, > > why I like it: > > - it is similar to SQLite3 very small, just one DLL or shared lib > - very portable across many platforms (DB is independent from byte order or 32bit vs. 64 bit) > - easy to use > - there is already a wrapper now for Pharo :) > > "UnQLite is a standard key/value store similar to BerkeleyDB, Tokyo Cabinet, LevelDB, etc. but, with a rich feature set including support for transactions (ACID), concurrent reader, etc. " > > http://unqlite.org/arch.html > http://www.methodsandtools.com/tools/unqlite.php > > Thanks > Torsten > >> Gesendet: Donnerstag, 16. Januar 2014 um 14:08 Uhr >> Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> >> An: "Torsten Bergmann" <astares(a)gmx.de> >> Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: Voyage backends >> >> Ho Torsten, >> >> wellâ¦ I planned Riak and maybe Tokyo and Omnibase (but when I find the timeâ¦ not much this days). I never thought about UnQLite (and also I never hear about it before :P ) >> >> cheers, >> Esteban >> >> >> On 16 Jan 2014, at 14:03, Torsten Bergmann <astares(a)gmx.de> wrote: >> >>> Hi Esteban, >>> >>> if I understood correctly Voyage is primarily an abstraction layer to access >>> NoSQL databases. Currently MongoDB or the image can be used as a backend. >>> >>> Are there any other backends available or planned (for instance to UnQLite using >>> PUnqlite [1]). >>> >>> As UnQLite is an embeddable database of really small size I guess it will be >>> as sucessful for the NoSQL world as SQlite3 was for the relation DBMS world >>> and supporting it as one possible backend for Voyage might be a real plus. >>> >>> At least I see that MongoDB is 102MB to install before one can use it and >>> unqlite library [2] is only a few KB ;) >>> So it is easier to package, deploy, ... - I havent checked the other features >>> of Mongo vs. PunQlite so far. >>> >>> Any comments about backends in general or UnQlite in particular? >>> >>> Thx >>> T. >>> >>> [1] http://forum.world.st/ANN-PunQLite-a-new-NoSQL-wrapper-for-Pharo-td4732162.… >>> [2] https://github.com/mumez/PunQLite/tree/master/binary >> >>

Jan. 16, 2014