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

Re: [Pharo-dev] [ANN] Transition of Ubuntu PPA maintenance

by Luc Fabresse

yes Thank you very much! #Luc 2014-12-04 23:40 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Markus Fritsche wrote: > >> Hello, >> >> The maintenance of the Ubuntu Pharo VM and .source Packages is being >> transferred from Damien Cassou to myself, Markus Fritsche. By trade, I >> am a Business Intelligence consultant, but always following what's going >> on with smalltalk/ pharo. >> >> If you experience any problems with the ubuntu packages, please feel >> free to contact me. I might not be able to help right away, but I'll try >> my best! >> >> Best regards, >> Markus >> >> >> > Thanks for this Markus. > cheers -ben > >

Dec. 5, 2014

Re: [Pharo-dev] Twittering Smalltalk

by phil＠highoctane.be

And a #pharo hastag. Le 5 dÃ©c. 2014 08:35, "Marcus Denker" <marcus.denker(a)inria.fr> a Ã©crit : > > > On Thu, Dec 4, 2014 at 10:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> >Do you have the links of all those tweets? I'd like to Storify some of >> them. >> >> All of them were from the ESUG twitter account. >> >> > The account is @esugsmalltalk: > https://twitter.com/esugsmalltalk > (603 followers) > > There is a pharo twitter account, too: > https://twitter.com/pharoproject > (1063 followers) > > Marcus > >

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Max Leske

> On 05 Dec 2014, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: >> >> Hi all, >> >> I'm just wondering. >> >> Would it work to have a package format based on Fuel? >> > I doubt it would work cross platform. I don't know how fuel serializes WideString, LargePositiveInteger, BoxedFloat64. These differ between smalltalk platforms. The source as string solves that. Strings are written as unicode string and numbers as certain number format etc. True. Cross dialect loading isnât something we encourage to do with Fuel. @Thierry You said something about partial loading: that will never be possible with Fuel because of its pickle format. To select any partial graph you have to first read the entire file and rebuild the graph first (ok, you donât strictly have to build the graph but you still need to read the entire file). > > Norbert > >> Would that make loading faster? >> >> Does it already exist? >> >> Thanks, >> >> Thierry >

Dec. 5, 2014

Re: [Pharo-dev] Twittering Smalltalk

by Marcus Denker

On Thu, Dec 4, 2014 at 10:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >Do you have the links of all those tweets? I'd like to Storify some of > them. > > All of them were from the ESUG twitter account. > > The account is @esugsmalltalk: https://twitter.com/esugsmalltalk (603 followers) There is a pharo twitter account, too: https://twitter.com/pharoproject (1063 followers) Marcus

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Norbert Hartl

> Am 04.12.2014 um 23:31 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: > > Hi all, > > I'm just wondering. > > Would it work to have a package format based on Fuel? > I doubt it would work cross platform. I don't know how fuel serializes WideString, LargePositiveInteger, BoxedFloat64. These differ between smalltalk platforms. The source as string solves that. Strings are written as unicode string and numbers as certain number format etc. Norbert > Would that make loading faster? > > Does it already exist? > > Thanks, > > Thierry

Dec. 5, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Thierry Goubier

Hi Eliot, thanks for that mail. 2014-12-04 23:59 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Thierry, > > On Tue, Dec 2, 2014 at 10:25 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2014-12-03 4:16 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> >>> Yes, but *I* care about the Monticello metadata. IMO its *better* than >>> the git metadata. >>> >> >> Eliot, you'll have to do better than just IMO on that one. >> > > Quite right. One benefit is that Monticello metadata, at least per-method > time stamps, are available for introspection inside the image. Just today > I was alerted of some bad code by a particular author and it was very > convenient to read all the methods by that particular author, which helped > me find another problem. I also like the free frorm of the middle of > method timestamps; I can and do annotate with labels for specific > refactorings. > I believe Dale will tell you that git will give you the ability to select a particular author work on a per-line basis, per-file basis (method or class, then), etc... Interestingly, the ability to comment at the file level is provided by github (well, in fact, it's a bit finer grained than that: it's commenting on a change in a file which fits your use case particularly well). So this means we could probably do better there. > > Another benefit is that Monticello is amenable for scripting much more > easily than git. I've been working on the SPur bootstrap fro a while now. > It is essentially complete. What the bootstrap does in Monticello is > construct patched versions of four packages, substituting specific methods > with replacements. Each patched package inherits both from its patched > ancestor and the package that was patched (a ladder like structure). This > allows Spur to keep up-to-date automatically w.r.t. Squeak trunk. > But this would also work over a git-based Monticello. And, as you describe it, it probably even been seen as a simple merge (it's a kind of by-hand merge you're doing, basically). This is one of the features I'm waiting Max for: the time he spent dealing with the low-level structure of the .git stuff(*) so that you can do exactly what you describe (or a Monticello merge) and commit that, and have it tracked as such. (*) Honestly, I didn't want to do it myself :( > > I'm also delighted that work like Chris Muller's version server is out > there. This is very nicely integrated to allow me to find out which > package versions contain versions of a particular method or class > definition. > I know that this version server exists, and I hoped that you would point it out, because I believe it is significant. Even if it is not usable in many professional settings, such as mine. As you probably do as well, I know what features are needed from such a server to make it distributed 'Ã la git'. > > Some of us work with *both*, and have code for going back and forth, so >> the *better*; bah. >> >> I also happens to know how long it takes to parse hundreds of monticello >> metadata files... and I wasn't impressed with the result. >> > > Yes, but this can be reengineered. Most things can be optimized. This > could be with a little effort. What's needed is to generate and maintain > momentum. That's what worries me about git integration. It's a slippery > slope towards giving up Monticello and just using git. And git itself will > one day be viewed as old-hat. Monticello should be easy to keep evolving. > It's in Smalltalk few chrissake. > Hey! You're talking to the guy who spent time making sure his git infrastructure would look and feel perfectly like a normal Monticello repository :) But, having the on-demand version metadata, on-demand creation of a specific history version, the speed at which you sync a remote, the fact that you can commit locally and sync later, the fact that querying for method or class versions is a lot faster... those are things that one should consider when thinking of improving Monticello. > > > >> >>> What's really lacking in Monticello is a) it's not high school so one >>> can't preen in front of the world on github and b) it has no support for >>> external files. Well, a) will be solved by growing up and b) can be solved >>> by building the solution. I know what I'd rather do. >>> >>> >>> [and apologies for being deliberately incendiary but I *hate* the >>> movement away from tools in Squeak/Pharo. It is a movement towards stasis >>> and death, and personally I'm enjoying life too much]. >>> >> >> You then have noticed that those threads are about working on tools? >> > > Yes, and that's why I'm writing to the thread. I hope that work on > integrating foreign file support, and integrating things like Chris > Muller's version server continues in the Pharo community. More than > anything I hope that Monticello remains a bridge between the Squeak and > Pharo communities. > I entirely agree with that :) Thierry > > >> >> >> Thierry >> >> >> >> > > > -- > best, > Eliot >

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Thierry Goubier

2014-12-04 23:43 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Thierry Goubier wrote: > >> Hi all, >> >> I'm just wondering. >> >> Would it work to have a package format based on Fuel? >> >> Would that make loading faster? >> >> Does it already exist? >> >> Thanks, >> >> Thierry >> > > What is your use case for needing it faster? > * Just every day developer use? > * CI automation? > * Something in production? > * Other? > cheers -ben > > The three first ones. Anything which improves loading speed / reduces memory footprint, really. Maybe the point to target is the version metadata. Thierry

Dec. 5, 2014

Re: [Pharo-dev] Monticello and Fuel

by Thierry Goubier

2014-12-05 0:08 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Thierry, > > On Thu, Dec 4, 2014 at 2:31 PM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> Hi all, >> >> I'm just wondering. >> >> Would it work to have a package format based on Fuel? >> > > It doesn't have to be based on Fuel. Monticello .mcz's are just zips that > contain any number of files: > > Archive: trunkpackages/Kernel.spur-eem.866.mcz > Length Date Time Name > -------- ---- ---- ---- > 15 08-07-14 09:12 package > 294780 08-07-14 09:12 version > 1370995 08-07-14 09:12 snapshot/source.st > 1442870 08-07-14 09:12 snapshot.bin > -------- ------- > 3108660 4 files > > Right now package and version are juts textual, and you've been > complaining about the parsing speed. It would be easy to extend the > package to include e.g. version.fuel. It is also a huge advantage to keep > both the .bin (a not-as-fast binary loading format similar in use to Fuel > but more primitive) along side the source code, because the source can be > extracted without a running system, and can be compiled if, for some > reason, binary loading fails. So instead of changing the format you could > simply augment it with a snapshot.fuel, modifying the writer to include it, > and modify the reader to use the .fuel if it exists. > Yes, or use an entirely different format. Whatever works. FileTree demonstrate that this can be done, and GitFileTree demonstrated that it could totally reproduce the mcz view on another tech repo. I'm more annoyed by the consequences of loading the full version file in the image. > > Would that make loading faster? >> > > Yes. But not hugely because the .bin already loads faster than the .st. > You might do some profiling? > Good suggestion. This is what I wanted to know. > > >> Does it already exist? >> > > Much of what you need is there. Use the Pharo, Luke. > This is a part of Pharo where I know my way :) Thanks, Thierry > > >> >> Thanks, >> >> Thierry >> > > > > -- > best, > Eliot >

Dec. 5, 2014

Woden

by volkert＠nivoba.de

I want to play a bit with Woden. What are the system requirements? What VM do i need? I tried to load Woden it into Pharo 3.0 (with Default Pharo VM) System: Ubuntu 14.04 x64. Volkert

Dec. 5, 2014

Re: [Pharo-dev] Code retrieval on primitive failed

by Eliot Miranda

Hi Vincent, On Thu, Dec 4, 2014 at 7:39 AM, Blondeau Vincent < vincent.blondeau(a)worldline.com> wrote: > Finally, I succeeded to retrieve my code ! > > > > I tried with the Cog VM Simulator to open my image. > > It opened my crashed image in the simulator without any problem (it seems > that the failing primitive has been caught). > > But I cannot interact with the image through the simulator workspace and > the morph. > > It seems that you can launch some code by doit to export a package named > MyPackage: > > > > cos systemAttributes > > at: 2 put: '-doit'; > > at: 3 put: (âRPackage > named:ââMYPackageâ) fileout â] > > > > But this did not work because my code contains shared pools and it cannot > be filed outâ¦ > > > > > > In parallel, I tried the other solution of Clement by changing the > bytecode in the .image itself. > > > > If the problem comes from a native boost primitive, you should use a cogvm > : (e.g. > http://www.mirandabanda.org/files/Cog/VM/VM.r3056/cogwin-14.29.3056.zip) > to launch the failing image. > > After that, you should see the crash log and see which are the code that > is failing (apparently one of the top method in the stack). > > The best is to have the Smalltalk code of this method because you have to > retrieve the associated bytecode. Else either you try to remember exactly > the content of the method or you take another method in the stack where you > have the code. > > > > Once you have identified the method, extract the bytecode: > > on Pharo4 with the right click on the method name and by printing âself > bytecode hexâ > > on Pharo3 inspect the class containing the method, find the right compiled > method and print âself bytecode hexâ > > > > After that open the broken image with a hexadecimal editor (I use HxD > under w7) (do a COPY before). > > Find the bytecode of the method and replace it by several 120 (78 in hex). > > As the bytecodes are not unique, it is possible to do several > replacements. If you donât want that, you can find another bytecode > available in the stack trace. Longest is the bytecode, less will be the > number of finding matches. > > > > Try to reopen your image with the cogwm. If it doesnât work either you > broke a critical method of your image (so try again with another bytecode) > either you have another failure so you start again to find the good method. > You make me proud!! That's a great way to do it. Brings back memories of similar holes I'v dug for myself and crawled out of. Well done! > > > Once you can open it. Save your code!!! > > The file out didnât work for me so I commited with Monticello in local and > it worked! > > > > So donât forget to commit! > > > > Vincent > > > > > > *De :* Blondeau Vincent > *EnvoyÃ© :* mercredi 3 dÃ©cembre 2014 18:41 > *Ã :* Pharo Development List > *Objet :* RE: [Pharo-dev] Code retrieval on primitive failed > > > > > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *De la part de* ClÃ©ment Bera > *EnvoyÃ© :* mercredi 3 dÃ©cembre 2014 17:54 > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] Code retrieval on primitive failed > > > > Please send the full stack trace. You don't have only three lines, do you ? > > > > No, indeed (the full stack is attached). > > > > There's one solution that Igor does sometimes that you can try...For that > you need to remember what code you changed that now crashes the image in > smalltalk. Do you know what code crash your image ? > > Could you rewrite it (exactly the same code) in a fresh image ? > > If so the process is as follow: > > - rewrite the crashing code in a fresh image > > - extract the bytecode from the compiled method > > - open a copy of your image with an hexadecimal editor, look for the > bytecode pattern, replace it by returnself (byte 120 the number of times > needed) > > - try open your copy. Do as little things as possible (typically, only > file out your packages, monticello will most probably not work) > > > > Ok I will try this but this is more a generic printing method that is the > problem (see trace)â¦ And not a specific methodâ¦ > > I tried but it seems not adapted to my caseâ¦ > > > > The alternative is to open your image on top of the cog simulator. Word > has been that there's a Pharo 3 image running the cog simulator, you can > use that to debug the code and fix it. Alternatively use a squeak vmmaker > image that you can build with this script: > > $ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image > > $ cd ./image > > $ ./buildsqueaktrunkvmmakerimage.sh > > You put a halt on the implementation of primitive 117 in the simulator > (named primitives call such as NB calls) to catch the crash and fix it from > there in the simulator. > > > > That seems better ! I am trying this way. > > > > Good luck and have fun :-) > > > > Thanks :) > > > > > > 2014-12-03 17:04 GMT+01:00 Blondeau Vincent < > vincent.blondeau(a)worldline.com>: > > Hello everyone, > > > > I am doing some developments with NativeBoost and unfortunaly I succeed to > save my image in a unstable state. > > I am using the last moose image i.e.: Pharo3.0 - Latest update: #30860. > > > > So when I want to launch my image, I get a primitive faillure. > > The interesting part of the stack trace is : > > Stack backtrace: > > [07EE7A1B] ??? + 0 in (null) > > [00539AB5] ??? + 1284789 in Pharo.exe > > > > Smalltalk stack dump: > > 0x2410b8 M NBFFICallout class(NBNativeCodeGen class)>retrySend: > 0x4c70b4c: a(n) NBFFICallout class > > 0x2410ec I NBFFICallout class(NBNativeCodeGen class)>retrySend: > 0x4c70b4c: a(n) NBFFICallout class > > 0x78a0d90 s RDoubleVector(OrderedCollection)>at: > > > > Then I wanted to retrieve my changes on a new image but, as the doIts are > not recorded, I have neither the method deletions nor all the operations on > classes nor the trait methods that are recorded as Doits with preamble: > Trait method. > > > > I tried to launch my image with squeak (which doesnât support NativeBoost) > to hope saving or commit my code. But as I am calling a primitive at > startup of the image to initialize the external environement. I got the > following trace : > > [31m==== Startup Error: PrimitiveFailed: primitive #isEnabled in > NativeBoost class failed > > [0mNativeBoost class(Object)>>primitiveFailed: > > NativeBoost class(Object)>>primitiveFailed > > NativeBoost class>>isEnabled > > NativeBoost class>>forCurrentPlatform > > NativeBoost class>>loadSymbol:fromModule: > > RSession class(Object)>>nbGetSymbolAddress:module: > > > > So what can I do to retrieve all my code without loose a day to rewrite it? > > > > Thanks in advance > > > > Vincent > > > > > ------------------------------ > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > -- best, Eliot

Dec. 4, 2014