- Pharo-users - lists.pharo.org

VM Crash after adding ram
by Ramon Leon Aug. 1, 2015

Aug. 1, 2015

So I've just upgraded my Ubuntu 14.04 machine to 16 gig of ram from 8 gig of ram and suddenly I can no longer start my Pharo VM; I don't understand why adding ram would make the vm stop working, I've been using it for year without problems. Can anyone interpret this: no objects after the end of memory pharo VM version: 3.9-7 #1 Tue May 6 08:26:29 UTC 2014 gcc 4.8.1 [Production ITHB VM] Built from: NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 6 2014 With: NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 6 2014 Revision: https://github.com/pharo-project/pharo-vm.git Commit: ef5832e6f70e5b24e8b9b1f4b8509a62b6c88040 Date: 2014-01-26 15:34:28 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14794 Build host: Linux wani07 2.6.24-32-xen #1 SMP Mon Dec 3 16:12:25 UTC 2012 i686 i686 i686 GNU/Linux plugin path: /usr/lib/pharo-vm/ [default: /usr/lib/pharo-vm/] C stack backtrace: /usr/lib/pharo-vm/pharo-vm[0x809add3] /usr/lib/pharo-vm/pharo-vm(error+0x17)[0x809af37] /usr/lib/pharo-vm/pharo-vm[0x806ee94] [0xb72ca6cd] [0xb72b0700] [0xb72ca2ca] [0xb72b0ccd] [0xb72b1989] [0xb72b0c5b] [0xb72b0700] [0xb8080227] [0xb807c7e1] [0xb807ca01] [0xb72b05c0] Smalltalk stack dump: 0xffa39fc8 M ExternalAddress class(Behavior)>allInstancesDo: 0xb86ca450: a(n) ExternalAddress class 0xffa39fec I ExternalAddress class>startUp: 0xb86ca450: a(n) ExternalAddress class 0xffa3a008 M ExternalObject class>startUp: 0xb86c8820: a(n) ExternalObject class 0xffa3a030 M [] in SmalltalkImage>send:toClassesNamedIn:with: 0xb75c4c24: a(n) SmalltalkImage 0xffa3a04c M BlockClosure>on:do: 0xc30bd160: a(n) BlockClosure 0xffa3a07c M [] in SmalltalkImage>send:toClassesNamedIn:with: 0xb75c4c24: a(n) SmalltalkImage 0xffa3a0a4 I OrderedCollection>do: 0xb75c4d54: a(n) OrderedCollection 0xffa3a0cc I SmalltalkImage>send:toClassesNamedIn:with: 0xb75c4c24: a(n) SmalltalkImage 0xffa3a0f8 I SmalltalkImage>processStartUpList: 0xb75c4c24: a(n) SmalltalkImage 0xffa3a124 I SmalltalkImage>snapshot:andQuit:embedded: 0xb75c4c24: a(n) SmalltalkImage 0xc26d5f90 s SmalltalkImage>snapshot:andQuit: 0xc2bff710 s WorldState class>saveAndQuit 0xc2bff76c s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0xc2bff7c8 s BlockClosure>ensure: 0xc26d5114 s CursorWithMask(Cursor)>showWhile: 0xc26d50a4 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0xc2bff824 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: 0xc2bff880 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: 0xc2bff8dc s MouseButtonEvent>sentTo: 0xc2bff938 s ToggleMenuItemMorph(Morph)>handleEvent: 0xc26d4f80 s MorphicEventDispatcher>dispatchDefault:with: 0xc26d4fdc s MorphicEventDispatcher>dispatchEvent:with: 0xc2bfefe0 s ToggleMenuItemMorph(Morph)>processEvent:using: 0xc2bff03c s MorphicEventDispatcher>dispatchDefault:with: 0xc2bff098 s MorphicEventDispatcher>dispatchEvent:with: 0xc2bff0f4 s MenuMorph(Morph)>processEvent:using: 0xc2bff150 s MenuMorph(Morph)>processEvent: 0xc2bff1ac s MenuMorph>handleFocusEvent: 0xc2bff208 s [] in HandMorph>sendFocusEvent:to:clear: 0xc2bff264 s [] in PasteUpMorph>becomeActiveDuring: 0xc2bff2c0 s BlockClosure>on:do: 0xc26d4e8c s PasteUpMorph>becomeActiveDuring: 0xc26d4e14 s HandMorph>sendFocusEvent:to:clear: 0xc2bff9f0 s HandMorph>sendEvent:focus:clear: 0xc26d4da0 s HandMorph>sendMouseEvent: 0xc26d4d38 s HandMorph>handleEvent: 0xc2bffa4c s HandMorph>processEvents 0xc2bffaa8 s [] in WorldState>doOneCycleNowFor: 0xc2bffb04 s Array(SequenceableCollection)>do: 0xc2bffb60 s WorldState>handsDo: 0xc26d4bd4 s WorldState>doOneCycleNowFor: 0xc2bffbbc s WorldState>doOneCycleFor: 0xc2bffc18 s PasteUpMorph>doOneCycle 0xc240332c s [] in Project class>spawnNewProcess 0xc2403078 s [] in BlockClosure>newProcess Most recent primitives at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: < basicNew: findSubstringViaPrimitive:in:startingAt:matchTable: new: basicNew new: at:put: at:put: perform:with: perform:with: at: at: perform:with: perform:with: someInstance nextInstance millisecondClockValue signal at:put: at:put: primSignal:atMilliseconds: millisecondClockValue wait primGetNextEvent: millisecondClockValue wait signal at:put: at:put: millisecondClockValue primSignal:atMilliseconds: millisecondClockValue wait signal wait atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance atAllPut: nextInstance stack page bytes 4096 available headroom 3300 minimum unused headroom 3540 (no objects after the end of memory) Aborted (core dumped) -- Ramon Leon

4 7

Pharo on 64bit Ubuntu
by Leo Noordhuizen Aug. 1, 2015

Aug. 1, 2015

Hello, I am running Ubuntu 15.04 64 bit and want to start experimenting with Pharo. What is the best way to get Pharo running in this environment ? It seems not to be straightforward, but I cant imagine that it has not been implemented before. Thanks, Leo Noordhuizen - The Netherlands

9 16

Linux Install -- problems, but eventually successful
by Shadowfirebird Aug. 1, 2015

Aug. 1, 2015

Hi all, I've been having trouble getting *any* sort of Smalltalk working on Linux. But ultimately I got Pharo (my first choice) working on Debian Jessie. It wasn't terribly hard in the end, but since the instructions at http://pharo.org/gnu-linux-installation#64-bit-System-Setup seem to be out of date, I thought it might be helpful to post something in case those in charge of that page would like to update. Since there is no issue tracker, I assume this is a good a place as any. ## Short Version ## * sudo dpkg --add-architecture i386 * sudo apt-get update * sudo apt-get install lib32zl lib32ncurses5 Note that there is no ia32-libs package on Jessie, as far as I can tell. (I have no idea whether you actually need to install lib32ncurses5, but those were what apt-get suggested, and it worked.) I do have a startup error -- "MessageNotUnderstood: EmbeddedFreeTypeFontInstaller>>failedToOpen:Index:" -- but it doesn't seem to break anything. ## Longer version / Rant ## Pharo turned out to be impossible on my netbook (where I would like to use it, sadly) because it is still running Crunchbang, which is Debian Woody under the hood. So in theory the fix from the 64bit install page should work. It doesn't, though -- some sort of problem with #! I suppose "The following packages have unmet dependacies: ia32-libs: Depends: ia32-libs-i386" Squeak, as downloaded from their site, has exactly the same problem. Pharo isn't in the Debian Repository, but an old version of the Squeak VM -- *just* the VM -- is. (Not sure what the point of that is.) It doesn't work with the current Squeak image from the website. I did eventually manage to get a compatible image ... via FTP. Good grief. (Good enough to learn the ropes, I suppose.) I really didn't want to go the Gnu Smalltalk road, but in desperation I tried it. Under both Crunchbang and Debian Jessie, the gst-browser package falls over immediately when you start it, a great big error trace I won't bother to paste here. These are packages in the *repository*. Is no-one maintaining them? The point of this rant is to give context to the following: thank you. Really, thank you, to the folks behind Pharo and everyone reading this. This is the problem with FOSS: blink, and yesterday's rave technology is gone. And Smalltalk is *important* -- I'm not a Smalltalk programmer, but every time I play with it I learn so much about OOP, programming, and good design of classes. And I keep coming back to try to work with it again, because it offers things I want and just can't get elsewhere. The idea that Smalltalk might one day just ... not run? Not worth thinking about. Okay, broke a cardinal rule here. Apologies for joining a mailing list and then immediately posting a long rant. Going to Lurk Mode now! Shadow.

6 11

Does RBImplementedButNotSent result in any critics for any of you?
by Paul DeBruicker July 31, 2015

July 31, 2015

It seems like its not testing for the right conditions any more and therefore not finding any messages that are implemented but not sent. I think this and the problem I was having the other day is from removing the use of the RBSmallLintContext class from checking criitcs issues. Why did you decide to do that?

2 3

Re: [Pharo-users] Personal wiki / information manager
by Evan Donahue July 30, 2015

July 30, 2015

Ah, yes, by 'offline' I did mean outside of the mailing list, but that was purely out of consideration for the list. If the list wants to hear it, far be it from me to keep it from them. For my part, I am a graduate student working on my dissertation, and I have been trying to build tools to facilitate that as I go, from taking and sharing notes, to visualizing primary material, to (eventually) organizing and writing the dissertation. I have been following Offray's updates with interest, as I think my goals are very much allied, but I am starting in a slightly different place, if I have understood correctly (research and organizing, and not yet writing, sharing, or publishing). My efforts thus far have been concentrated in two repositories: Chancery (http://smalltalkhub.com/#!/~EvanDonahue/Chancery) is an early prototype for a note taking system. I am coming from taking notes in emacs org-mode, and so Chancery right now is the most straightforward collapsable tree outliner/note taker that could give me functionality basically equivalent to what I had in org-mode, and serve as a platform to co-evolve my research methods and their supporting technology. The near-term goals for this involve adding metadata (authors, dates, etc) to the sources I am annotating and using that for various kinds of historical visualization (and further, attendant annotation) eg who wrote what when, referencing who, influenced by what, etc), and can I edit all that directly in its graphical form. The status of this project is that it is usable by myself and those I have worked with on it (and I use it as my primary note taking system), but I'm not sure what it would look like to someone loading it at the moment (no real intro/docs, as it was just a quick prototype to provoke further design discussion). Trantor (http://smalltalkhub.com/#!/~EvanDonahue/Trantor) is a disttributed p2p system for incrementally keeping data structures in sync between multiple, asynchronously connected pharo instances across the internet without requiring human attention to resolve merge conflicts (think laptos where data is edited offline and then automatically synced when they connect to one another); it is my answer to sharing and collaboration for things created in Chancery (although it is a more general purpose project). Functionally, Trantor provides a set of common datatypes (set, dict, text blob, etc) and a means to run nodes and peer them for synchronization of said datatypes. The goal with respect to Chancery/personal information management is being able to easily grab some structured set of notes or writing out of the note taking system and share it with collaborators or colleagues with a button click, and without having to go through the whole export/send/manage versions dance. This project is about 85% complete, the proof of concept works, it just needs a big refactor to make it usable and quash some bugs. I guess my observations on using Pharo thus far are first, that it is absolutely ideal for evolving prototypes, since you get a sort of poor man's gui and persistance (object inspector + image serialization) basically for free, which is 90% of the work of such a simple information management app prototype. I have a fully functional tree outliner at a point when in another language I would still be trying to hack a low functionality command line interface. The other thing I've found refreshing is that my application can live as one among many within the image, sharing data with other programs by passing objects around in a way that is impossible to do with a standalone application running on a modern operating system. the dream of the web is, I think, heading more in this direction, but working with the browser (as I was before I came to pharo) requires coordinating a separate server process, compressing everything into http/html/json, and a host of other problems that vanish when you can just serialize objects between pharo instances. In short, I'm getting a lot done in this language and I expect I'll be around for a while. Cheers, Evan

4 3

Pillar and Beamer
by Peter UhnÃ¡k July 30, 2015

July 30, 2015

Hi, there was a presentation (or show us your project) about Pillar and (LaTeX/)Beamer at ESUG if I am not mistaken. However I don't think there are videos available from the uni, so is more information available somewhere? Thanks, Peter

3 2

Re: [Pharo-users] [Moose-dev] Re: Script of the day
by H. Hirzel July 30, 2015

July 30, 2015

Is it possible to use a tree map? --Hannes On 7/30/15, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > I gave a try, and I did not find anything weird. > I guess your document folder contains many files, as Doru said > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >> Frankly I dont mind big images or big data , neither I share the obsession >> to shrink things down to few mbs in a time that we are talking in TBs . >> >> Anyway you asked for the image and this is a link to it >> >> https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 >> <https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0> >> >> I dont think you will find anything abnormal about it though. >> >> I was wondering whether it would worth the effort beyond the unit tests >> that check for behaviour of the code to have also benchmark tests that >> will have to pass specific standards so that specific method must perform >> under a strict timetable specific tasks, this way CI may alert not only >> unit tests that fail but also benchmarks that fail , automagically. >> >> Maybe some food for thought. >> >> Personally I am far more worried how much CPU Pharo consumes than how much >> RAM. >> >> On Wed, Jul 29, 2015 at 11:54 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com >> <mailto:i.uhnak@gmail.com>> wrote: >> Not sure if there is any downside (I've been using it for a long time >> without problems), but image cleanup often does wonders for me. >> >> Moose image >> 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 >> MB >> and I even had situations where it went from ~600 MB to ~60 MB. >> (As to why my images are so massive... right now there are 19 windows >> opened inside most of them with opened roassal visualization... and I am >> saving like every five minutes... but that is just a guess.) >> >> But image cleanup is supposed to break things, so better to backup the >> folder first. >> Plus is cache really necessary? I mean it's a cache. .image + .changes >> should usually suffice. >> >> Peter >> >> On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios(a)gmail.com >> <mailto:kilon.alios@gmail.com>> wrote: >> Tudor I dont know if you received my message but I already answered that >> with this: >> >> "ah ok then its normal. Yes the structure is extensive, its 13 folders >> (the rest 71 are files some of them very big), I would not be surprised if >> each contains 100 files in its own subfolders." >> >> >> >> On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> Hi, >> >> But, do you confirm that you have many files under the mentioned folder? >> >> Cheers, >> Doru >> >> >> >> On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios(a)gmail.com >> <mailto:kilon.alios@gmail.com>> wrote: >> the image is 180 mb, changes are another 15, there are several other >> folders that raise the total size to 250 mb, monticello-cache and >> github-cache prodominately. >> >> Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me >> 1-2 hours to upload on this connection. So if you guys still need the >> image i can upload tommorow from work, though it seems my slow down is >> normal. >> >> Afterall I am sure you can test it yourselves on complex file structures >> to see if it has delays as long as 20 minutes. >> >> >> >> On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>> wrote: >> >> > On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios(a)gmail.com >> > <mailto:kilon.alios@gmail.com>> wrote: >> > >> > well i can send you the image tommorow because its huge (200 MB ziped) >> > for my pathetically slow internet connection at home. I will send it >> > from work which is 8 times faster. >> >> If the image is 200 MB zipped, how large is it in its normal state ? >> >> For me, a 100 MB image file is already quite large, that would compress to >> maybe 20/30 MB. >> >> This doesn't sound right to me, unless you explicitly tried to store a lot >> of data. >> >> Maybe something else is wrong that would explain the slowness. >> >> > I can tell you that I am on MacOS Yosemite , I get my image with >> > pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items >> > are folders that contain many sub folders. No idea if that matters. >> > >> > I got Roassal 2 using the Package Browser in Pharo 5 (the new >> > configuration browser). >> > >> > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel >> > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> > Are you using windows? I know it may has problems regarding the source >> > code. You have 84 items and the visualization is slow? How is this >> > possible. >> > >> > Can I have a look at your image? >> > >> > Cheers, >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios(a)gmail.com >> >> <mailto:kilon.alios@gmail.com>> wrote: >> >> >> >> thats ok it unfroze after 20 minutes or so . I managed to inspect the b >> >> but its incredible slow to navigate and use . Even moving the inspector >> >> around is incredible slow. My Documents folder contains 84 items, maybe >> >> it cant handle so well this amount of datea ? >> >> >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >> >> <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >> Ohâ¦ sorry. Was not my intention >> >> >> >> Alexandre >> >> -- >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios(a)gmail.com >> >>> <mailto:kilon.alios@gmail.com>> wrote: >> >>> >> >>> that was a nice way to freeze my image, thank you :D >> >>> >> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >> >>> <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >>> Hi! >> >>> >> >>> Just to share a couple of experiment. I have tried the following in a >> >>> playground: >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >>> b := RTMondrian new. >> >>> >> >>> b shape rectangle >> >>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color >> >>> red. >> >>> b nodes: FileLocator documents allChildren. >> >>> b edges connectFrom: #parent. >> >>> b normalizer >> >>> normalizeSize: #size using: #sqrt. >> >>> b layout tree. >> >>> b >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >>> >> >>> It shows a tree of the file system. Thanks to GT, simply clicking on a >> >>> file may show you the content and other things. >> >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >> >>> >> >>> You can also use the cluster layout: >> >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >> >>> >> >>> I have tried this on OS X, since the pointed folder is ~/Documents. >> >>> >> >>> Cheers, >> >>> Alexandre >> >>> -- >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Moose-dev mailing list >> >>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >

3 3

AST visualization with Roassal
by Mark Rizun July 30, 2015

July 30, 2015

Hi, everyone! First of all, using Roassal is fun and effective :) But while working on AST visualization I found that sometimes Roassal builds wrong tree layout (or maybe I'm just doing something wrong). For instance, try two following scripts in playground: ************************* #1 | ast builder | ast := RBParser parseExpression: 'self foo. self foo'. builder := RTMondrian new. builder shape ellipse size: 15. builder nodes: ast allChildren. builder edges connectFrom: #parent. builder layout tree. builder build. builder view ************************* ************************* #2 | ast builder | ast := RBParser parseExpression: 'self foo. super foo'. builder := RTMondrian new. builder shape ellipse size: 15. builder nodes: ast allChildren. builder edges connectFrom: #parent. builder layout tree. builder build. builder view ************************* First script builds wrong tree. I think it's because somewhere in roassal objects (in this case ast nodes) are compared by value. That is why when we have two equal receivers in script #1 it fails to build a tree. Thanks, Mark -- View this message in context: http://forum.world.st/AST-visualization-with-Roassal-tp4840243.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

4 8

ViDI error: variable named "aModuleName" in NativeBoost>>#loadModule:
by Rafael Luque July 30, 2015

July 30, 2015

Hi, I installed ViDI on Pharo 4 following the project instructions detailed in its GitHub page: Gofer new smalltalkhubUser: 'YuriyTymchuk' project: 'Configuration'; configurationOf: 'Vidi'; load. #ConfigurationOfVidi asClass loadStable When I launch a review session over any package I always get the following error: "Could not find accesor for variable named "aModuleName" in NativeBoost>>#loadModule:" I'm very interested in this kind of quality assurance tools, so any help will be very welcomed. Thank you.

4 10

Recoverying a crashed Moose image/Pharo5
by Hilaire July 30, 2015

July 30, 2015

Hello, I have a Moose 6.0 image with several Playgrounds. Since this morning, exactly when I want to make a demo[1], it crashes immediately. I remember yesterday I got an error when saving, Pharo said something like 'This error should not happen'. The OS windows open then close almost immediately (dump included). Could it be related to Athens or FreeType plugin access? The image went about 113MB. The used VM works fine with a fresh Moose6.0 image. Btw, the http://www.moosetechnology.org/ is down right now. I would like to recover the script codes in the playgrounds, is there a way to access it? Thanks Hilaire [1] Hopefully I can demo with a fresh image of Moose -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

6 9