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

Re: [Pharo-project] Fuel serialization - feature/bug

by Mariano Martinez Peck

On Mon, Jun 13, 2011 at 11:28 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > In my test case for serializing a Pier kernel with Fuel, a FSMemoryStore > (from the FileSystem package) is used. I really didn't understand, sorry :( Why the following is not enought? (FLSerializer on: myStream) serialize: myPRKernel. and (FLMaterializer on: myStream) materialize > The FSMemoryStore holds the "file" bytes in a ByteArray. During > serialization, I got a stack trace with KeyNotFound due to > FLSerializer>>nextPutReferenceTo: when the object is the "file" ByteArray. > > Since this ByteArray is where the serialization is being written to, mmmmmm so you are using a stream to serialize and such stream is also being refenced from the object to serialize? > then it's hash value is changing, so Fuel serialization cannot find it in > the instancesIndex. > > I think this is expected behaviour, and the fix is to not serialize certain > inst vars. I was using the "stable" 1.4 version. Do I need to change to the > 1.5 baseline to get the #fuelIgnoredInstanceVariableNames feature? > > -- > Yanni > > > -- Mariano http://marianopeck.wordpress.com

June 13, 2011

[Pharo-project] Fuel serialization - feature/bug

by Yanni Chiu

In my test case for serializing a Pier kernel with Fuel, a FSMemoryStore (from the FileSystem package) is used. The FSMemoryStore holds the "file" bytes in a ByteArray. During serialization, I got a stack trace with KeyNotFound due to FLSerializer>>nextPutReferenceTo: when the object is the "file" ByteArray. Since this ByteArray is where the serialization is being written to, then it's hash value is changing, so Fuel serialization cannot find it in the instancesIndex. I think this is expected behaviour, and the fix is to not serialize certain inst vars. I was using the "stable" 1.4 version. Do I need to change to the 1.5 baseline to get the #fuelIgnoredInstanceVariableNames feature? -- Yanni

June 13, 2011

Re: [Pharo-project] Toward MVP

by Schwab,Wilhelm K

Attached is code to produce something I need. It shows a list of items; click one and the text goes into the box below the list. The user can also type into that box; there is no sense of responsibility about saving the user's work. The mind set is that the list provides most things of interest, and it should be possible to "say anything" just in case. Click the button, and the text in the bottom field goes into a log file, complete with time stamp. It's not big deal, but neither should be creating it. Start with a model: EventLogger>>initialize super initialize. quickList := ListModel new list:#( 'Start' 'BP down' 'BP up' 'End' '***SNAFU***' ); yourself. fileSequence := ... "the log" Add the attached code. Among the important features are transparent handling of the selection index for the list and having something (following Dolphin, call them presenters) between the model and views (morphs). Models should not know or care about their selection index; the morph/view should do that (in Pharo, the ListPresenter is the natural home for it), and can do so in a way that "just works" for most purposes. The text presenters have been more trouble than I expected, but they bring with them some very important concepts. Dolphin's ViewResource is looking for a home (whether it will find one is open for bets), and the volley of events between model, view and presenter is starting to appear. Among the important tests (not yet realized as unit tests - sorry) is one model with multiple views; change the model and the views update. Dolphin's layout managers are very powerful, and while the pieces to make them exist in Pharo, I have yet to master their use. A common trap is to use top-level views when something composable is possible and desirable. I am not yet sure what to do about that. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, June 04, 2011 3:48 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. On Jun 4, 2011, at 6:55 PM, Schwab,Wilhelm K wrote: > Stef, > > Thanks for the homework assignments :) > > I have not specifically looked at simple grid in 1.3, but I will do so - gotta go for a run first. > > My MVP code is not yet available, but I intend to release it once it is remotely worth having. I was pleasantly surprised to find more than I thought I had working. Maybe I should soon put a "first draft" where people can see it. yes please do :) > The design (if that word applies<g>) is a compromise between Dolphin's approach to GUIs where it makes sense to follow them, realizing that the Dolphin view composer isn't here, some "going along with the flow" where Polymorph makes things too easy to ignore, and finally some Seaside influence. > > Dolphin uses a GUI to assemble views. I am planning to do that with code, but ultimately that should not be forced. It will take some time to balance all of that. > >>> did you check HPI library or void nullpointer widgets? > > I am not familiar with them, but I will look. I suspect I am finding smoke screens on HPI, I think that they have some nice widgets to get inspired from. > but the null pointer widgets look like I found what you have in mind. It looks like you are "thinking big," which is great. I am not a big believer that native widgets equate to speed, but, there are times when some native code goes a LONG way in that direction. I would like to see us able to use one native window per tool shell, if not be able to go completely native. I think it would be painful, but ultimately good for us. I'm not talking about native. just getting some good foundation. > > Short term, I am not so much thinking of replacing the GUI (though my stuff would hopefully run on top of any widgets - with some work) as I am with reducing the redundant work that goes in to a GUI, and moving us toward MVP. The latter is for two reasons: (1) it is a nice framework; (2) I have a lot of old code that I would like to see have a home on Linux. yes work on it and let us see it. > > Bill > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, June 04, 2011 12:23 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. > > On Jun 4, 2011, at 6:08 PM, Schwab,Wilhelm K wrote: > >> I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations. >> >> ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why? > > > did you check on 1.3 because igor and ben spent some time optimizing it a bit. > >> I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time. > > > I'm interested in that MVP framework. > Do you have some code somewhere? > > With igor we discussed about killing pluggable.... but for now one step at the time. > > >> The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason? > > did you check HPI library or void nullpointer widgets? > > I would love to have a gorup of people pushing that. >> >> Bill >> >> >> >> >> > > >

June 13, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Mariano Martinez Peck

On Thu, Jun 9, 2011 at 3:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Martin and Mariano, > > a couple of questions. What's the right way to exclude certain objects > from the serialization? Is there a way of excluding certain inst vars from > certain objects? > > Eliot and the rest....Martin implemented this feature in Fuel-MartinDias.258. For the moment, we decided to put #fuelIgnoredInstanceVariableNames at class side. Behavior >> fuelIgnoredInstanceVariableNames "Indicates which variables have to be ignored during serialization." ^#() MyClass class >> fuelIgnoredInstanceVariableNames ^ #('instVar1') The impact in speed is nothing, so this is good. Now....we were thinking if it is common to need that 2 different instances of the same class need different instVars to ignore. Is this common ? do you usually need this ? We checked in SIXX and it is at instance side. Java uses the prefix 'transient' so it is at class side... thanks -- Mariano http://marianopeck.wordpress.com

June 13, 2011

Re: [Pharo-project] WindowOrganiser (was: Tab widget improvements)

by StÃ©phane Ducasse

gary we can either push it in 1.3 or wait a bit and push it when we open 1.4. What would you prefer? Marcus prefer that we do not generate more bugs now that we are closing 1.3 I do not know what is the impact of your so let us know. Stef On Jun 13, 2011, at 5:04 PM, Gary Chambers wrote: > For the brave, attached script (no chance of working with a filed out changeset as order is important). > > Refactors TopWindow on SystemWindow to currentWindow on WorldState, along with many other simplifications. > > The upshot is that there are far fewer direct class references and should help somewhat with multiple worlds, though a few menu options refer to SystemWindow class still (further work required there). > > Propbably best to close all windows after filing in. > > Just a start on the refactoring but this is something best done in small steps. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, June 10, 2011 4:05 PM > Subject: Re: [Pharo-project] WindowOrganiser (was: Tab widget improvements) > > > > >> Evidently not last... >> Workaround for embedded windows to remember keyboard focus. >> Really the whole active/passivate thing for windows needs a good cleanup and refactoring. > > please please please > all these elements should get lean and clean. > > > <TopWindowRefactoring.st>

June 13, 2011

Re: [Pharo-project] WindowOrganiser (was: Tab widget improvements)

by Gary Chambers

For the brave, attached script (no chance of working with a filed out changeset as order is important). Refactors TopWindow on SystemWindow to currentWindow on WorldState, along with many other simplifications. The upshot is that there are far fewer direct class references and should help somewhat with multiple worlds, though a few menu options refer to SystemWindow class still (further work required there). Propbably best to close all windows after filing in. Just a start on the refactoring but this is something best done in small steps. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, June 10, 2011 4:05 PM Subject: Re: [Pharo-project] WindowOrganiser (was: Tab widget improvements) > Evidently not last... > Workaround for embedded windows to remember keyboard focus. > Really the whole active/passivate thing for windows needs a good cleanup > and refactoring. please please please all these elements should get lean and clean.

June 13, 2011

Re: [Pharo-project] [Pharo-users] Pharo on Fedora 15_64

by bblochl＠arcor.de

----- Original Nachricht ---- Von: Toon Verwaest <toon.verwaest(a)gmail.com> An: pharo-project(a)lists.gforge.inria.fr Datum: 13.06.2011 16:33 Betreff: Re: [Pharo-project] [Pharo-users] Pharo on Fedora 15_64 > ls appears to be > alias ls="ls --color=auto" > :) > > Now I'm just guessing: you probably didn't install 32-bit support for > you machine, so ld-linux.so.2 isn't around; and that's the "interpreter" > that's suppose to setup a memory image based on an ELF image (basically > unpack the binary into memory so that it can be executed). This is > different from 32-bit ELFs than for 64bit ELFs; and since you probably > DO have the interpreter for 64 bit, I'm guessing this is the interpreter > for 32 bit... on which COG runs anyway ;) > > So in short: find out what the 32bit libs are on fedora and install them. > > A random google search gave me the following. Didn't test it though... > > yum install ld-linux.so.2 > > And I don't know why you are trying to run readelf ... but you'll > probably have to install that too if you want it ;) > > cheers, > Toon > > Why are you doing ldd `which ls` anyway? > > On 06/11/2011 10:42 PM, Mariano Martinez Peck wrote: > > > > > > On Sat, Jun 11, 2011 at 10:13 PM, <bblochl(a)arcor.de > > <mailto:bblochl@arcor.de>> wrote: > > > > I actually installed Fedora 15 with GNOME 3 on a AMD-64 a couple > > of days back and tried to run Pharo, latest stable version and ran > > into some problem: > > > > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ ./Pharo.sh > > ./Pharo.sh: > > /home/bb/Pharo/Pharo-1.2.1-CogOneClick.app/Contents/Linux/squeakvm: > /lib/ld-linux.so.2: > > bad ELF interpreter: Datei oder Verzeichnis nicht gefunden > > ./Pharo.sh: Zeile 16: > > /home/bb/Pharo/Pharo-1.2.1-CogOneClick.app/Contents/Linux/squeakvm: > Erfolg > > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ ldd `which ls` > > alias: > > ldd: ./alias: Datei oder Verzeichnis nicht gefunden > > ls='ls: > > ldd: ./ls='ls: Datei oder Verzeichnis nicht gefunden > > --color=auto': > > ldd: ./--color=auto': Datei oder Verzeichnis nicht gefunden > > /bin/ls: > > linux-vdso.so.1 => (0x00007fffc7bc8000) > > libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003761400000) > > librt.so.1 => /lib64/librt.so.1 (0x00007f5c7914b000) > > libcap.so.2 => /lib64/libcap.so.2 (0x0000003764400000) > > libacl.so.1 => /lib64/libacl.so.1 (0x000000376e800000) > > libc.so.6 => /lib64/libc.so.6 (0x00007f5c78db1000) > > libdl.so.2 => /lib64/libdl.so.2 (0x00007f5c78bac000) > > /lib64/ld-linux-x86-64.so.2 (0x00007f5c79367000) > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5c78991000) > > libattr.so.1 => /lib64/libattr.so.1 (0x000000376a800000) > > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ readelf -l a.out > > bash: readelf: command not found... > > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ > > > > What to do now?? > > > > Regards > > > > B. Blochl > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > Thanks for answering, Toon! The problem is already solved. (See my mail from 12.06.2011 22:00) I argue, that ld-linux.so.2 is not the only missing 32bit lib. But if you can make this shure, it is an interesting result. Concerning your question: "Why are you doing ldd `which ls` anyway?" I did not do it, this will be done by the launch of Pharo.sh. Regards B. Blochl

June 13, 2011

Re: [Pharo-project] [Pharo-users] Pharo on Fedora 15_64

by Toon Verwaest

ls appears to be alias ls="ls --color=auto" :) Now I'm just guessing: you probably didn't install 32-bit support for you machine, so ld-linux.so.2 isn't around; and that's the "interpreter" that's suppose to setup a memory image based on an ELF image (basically unpack the binary into memory so that it can be executed). This is different from 32-bit ELFs than for 64bit ELFs; and since you probably DO have the interpreter for 64 bit, I'm guessing this is the interpreter for 32 bit... on which COG runs anyway ;) So in short: find out what the 32bit libs are on fedora and install them. A random google search gave me the following. Didn't test it though... yum install ld-linux.so.2 And I don't know why you are trying to run readelf ... but you'll probably have to install that too if you want it ;) cheers, Toon Why are you doing ldd `which ls` anyway? On 06/11/2011 10:42 PM, Mariano Martinez Peck wrote: > > > On Sat, Jun 11, 2011 at 10:13 PM, <bblochl(a)arcor.de > <mailto:bblochl@arcor.de>> wrote: > > I actually installed Fedora 15 with GNOME 3 on a AMD-64 a couple > of days back and tried to run Pharo, latest stable version and ran > into some problem: > > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ ./Pharo.sh > ./Pharo.sh: > /home/bb/Pharo/Pharo-1.2.1-CogOneClick.app/Contents/Linux/squeakvm: /lib/ld-linux.so.2: > bad ELF interpreter: Datei oder Verzeichnis nicht gefunden > ./Pharo.sh: Zeile 16: > /home/bb/Pharo/Pharo-1.2.1-CogOneClick.app/Contents/Linux/squeakvm: Erfolg > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ ldd `which ls` > alias: > ldd: ./alias: Datei oder Verzeichnis nicht gefunden > ls='ls: > ldd: ./ls='ls: Datei oder Verzeichnis nicht gefunden > --color=auto': > ldd: ./--color=auto': Datei oder Verzeichnis nicht gefunden > /bin/ls: > linux-vdso.so.1 => (0x00007fffc7bc8000) > libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003761400000) > librt.so.1 => /lib64/librt.so.1 (0x00007f5c7914b000) > libcap.so.2 => /lib64/libcap.so.2 (0x0000003764400000) > libacl.so.1 => /lib64/libacl.so.1 (0x000000376e800000) > libc.so.6 => /lib64/libc.so.6 (0x00007f5c78db1000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f5c78bac000) > /lib64/ld-linux-x86-64.so.2 (0x00007f5c79367000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5c78991000) > libattr.so.1 => /lib64/libattr.so.1 (0x000000376a800000) > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ readelf -l a.out > bash: readelf: command not found... > [bb@localhost Pharo-1.2.1-CogOneClick.app]$ > > What to do now?? > > Regards > > B. Blochl > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 13, 2011

[Pharo-project] [update 1.3] #13262

by Marcus Denker

13262 ----- Issue 4393: Move CrLfFileStream to Deprecated13 http://code.google.com/p/pharo/issues/detail?id=4393 Issue 4392: move Utilities and Preferences from Deprecated12 to Compatibility package http://code.google.com/p/pharo/issues/detail?id=4392 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 13, 2011

[Pharo-project] [TODO] 1.3

by Marcus Denker

Core ==== Failing tests: 0 Bug Tracker: 2, http://code.google.com/p/pharo/issues/list?cursor=4392&q=milestone%3D1.3 Issue 4328: Transcript: 5) Update problem when evaluating 1 to: 30 do: [: x | Transcript cr; show: x. (Delay forSeconds: 0.2) wait.]. Issue 4329: Transcript: 4) clear on cmd-s Next step: Fenando posted a changeset for testing in 4328. Needs testers. Full: ==== Failing tests: 1 But tracker: 2 http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3-DevImage Issue 4390: OCompletion does not respect #enabled setting; it has no "off switch" Issue 4394: GoferApiTest >> testRepositoryErrors fails in Full but not in Core -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 13, 2011