February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Creating a file with FS

by StÃ©phane Ducasse

>> - it still returns the FSReference... > > what you want is the following I guess: > > (wk / 'foo') writeStreamDo: [ :s| > s << 'bar' ]. > > since that will > - create also create a new file. > - ensure closing the stream Yes I did the same. >> FSReference>>writeStreamDo: doBlock ifPresent: presentBlock >> "Create a file if not present and execute doBlock (with a stream) as argument, if the file is present execute the presentBlock." >> ^ self isFile >> ifTrue: [ presentBlock value ] >> ifFalse: [ self writeStreamDo: doBlock ] >> >> FSReference>>writeStreamIfPresent: presentBlock >> "Return a writestream on the receiver if it does not already exist or execute the presentBlock with no argument" >> ^ self isFile >> ifTrue: [ presentBlock value ] >> ifFalse: [ self writeStream ] >> >> >> I do not get why we do not get as argument to the presentBlock the file itself? > > indeed, a [... cull: self] might make sense here :) >

Feb. 6, 2012

[Pharo-project] FOSDEM devroom

by Stephan Eggermont

Yesterday we had a nice day filled with great presentations. Getting to Brussels the day before proved to be a challenge, as the Dutch railways showed to have lots of trouble with 3 cm of snow and a cold night. Andy showed us a good place to eat and talk near the Central Station. In the end all presenters managed to be on time and the whole day ran smoothly. As the devroom was the second day of FOSDEM, we thought it wise not to start too early. That was a good idea, as the ULB was still very quiet when Norbert showed us how to create REST/json/xml based services. Markus followed with the Pharo Vision. Gradually more people came to the devroom until the jQueryMobile presentation was so filled that we had to refuse people entering the room. The Amber presentation also attracted a lot of people new to smalltalk. The ability to create a fast feedback cycle apparently is a major issue for javascript developers. The progress made since ESUG2011 is impressive. The next subjects (working with many cores, making smalltalk fast, spoon) still attracted over 40 participants. The introduction to smalltalk attracted quite a lot of young developers. Some remarks by participants: - a consistent set of keybindings, allowing switching between windows is essential (a developer who has trouble using a mouse for longer periods); - current developers are no longer used to free floating windows, it doesn't matter if it is better, to attract new people you need to remove barriers to entry (a freepascal maintainer); - I would have expected to have started with the basics (we focused on the things we experienced as difficult and different, using the different inspectors and browsers to navigate a large codebase, debugger driven development) And some reminder for ourselves - Tests for the domain model are not enough to ensure that the whole application works correctly; - Throw away old builds; - Check if there are enough power strips. I very much liked talking to people otherwise only known from the mailing lists and the cross-pollination between the different dialects. I would have liked to have more time for discussions. A lunch break might be a good idea. And finally a remark for next years devroom manager: don't expect to see much from FOSDEM :) Stephan Eggermont

Feb. 6, 2012

Re: [Pharo-project] pharo vision

by Nick Ager

Hi Stef, Similarly to Philippe my feedback is based on a Seaside/web centric view of how I use Pharo. I'd echo Philippe's concern about looking carefully at how much effort is required to rework Morphic vs using an existing UI library or WebView. From a web centric view I'd emphasis building a remote browsing interface over significant Morphic work. At FOSDEM this weekend I was impressed with the progress Craig Latta has made on spoon recently [1] [2]. Does his work on remote browsing and micro kernels fit into a future Pharo? As I develop with Pharo and deploy with Gemstone, maintaining some level of compatibility between Smalltalks is important. I note the problem raised with XML compatibility between dialects [3]. So the ability to maintain a compatibility layer such as Grease is important, as is the ability to re-use packages between Pharo and Gemstone. [1] http://thiscontext.wordpress.com/ [2] http://netjam.org/spoon/naiad/ [3] http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg56924.ht… On 5 February 2012 17:43, Philippe Marschall <kustos(a)gmx.net> wrote: > On 30.01.2012 09:24, StÃ©phane Ducasse wrote: > > OK, so here's my take. I try to not turn this into a wish list. > > Rich libraries > While I obviously agree that rich libraries are valuable I believe it's > important to have clear guidelines to what should be part of Pharo and what > not. In one extreme I could have everything from SqS be part of Pharo. I > don't think this is the idea. You don't want to have the same discussion > for every library whether it should be part of Pharo. > > FFI > First I think we need to have a problem statement. We want to be able to > use libraries written in C from Pharo. We don't implement them in Pharo > because we don't have the resources to develop them or Pharo is unsuited > for the task. This sucks because it's no longer "turtles all the way down" > but better than nothing. Since blocking C calls block the entire VM until > the call returns we need to have "threaded-FFI". > Yes, I do think that callbacks should be mentioned here. Currently the > situation as I understand it is: > - use FFI for call-outs > - use Alien for call-backs > - use NativeBoost for faster callouts? "portable plugins"? > It would be really nice to have a better, more integrated solution here. > If that results in something that's more than a one liner for a C call > that's fine with me. > > 64 bit > I think it's important to make a distinction between 64bit images and 64 > bit VMs. > > 64 bit VMs > Unless you on a small device current systems are 64bit. While most of them > offer some sort of way for running 32bit applications this cannot be the > way forward since: > - it clearly marks the application as legacy > - you can only talk to 32bit libraries (see FFI) > - we don't know how long this will still be supported (Apple anybody?) > I don't know how much work is required to make Cog run on 64bit. > > 64bit images > While it would be nice to have multi gigabyte images (maybe not) I don't > think it's realistic to assume we have the resources to come up with a GC > that can handle such images. > > SOAP > SOAP is a massive resource sink [1]. Yes it would be nice to have good > support but the cost is prohibitive and better spent on other things. > > Sockets > I don't think the socket layer is holding us back. Sure, it's ugly, sure, > it can â and should â be improved, but it's not holding us back. IMO it's > missing four things: > - better documentation with examples, this is important and relatively > easy to do > - SSL, this is "just" an issue for clients since servers are fronted > anyway. I know Sven's working on this. > - sendfile support. This would allow us to send files efficiently over > the network without touching user space. Since we're fronted anyway this is > not a big deal. > - asynchronous support. This would allow us to have a large amount of > open connections for things like WebSockets. May be too much work to get it > working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we > still need to write quite some infrastructure on top of it so you'll > probably want to deprioritize if not drop this. > I know I have a narrow Seaside-centric focus here. > What would be nice is to have a generic client-server framework (how many > times have I written a socket-loop?) but I don't think this should be part > of Pharo. > > Load balancer > I don't think this needs to be part of Pharo. Apache already does this. > > UI frameworks: > Have you considered cutting your losses? You have your existing > infrastructure that requires more resources than you have and if you could > you rewrote it. Then in addition you have new requirements and you want to > come up with new paradigms. I feel this alone can consume more your entire > resources. > Options that I would consider: > - status quo, maintenance only, no further development > - drop UI entirely, go for something like embedded WebKit > - make it somebody else's problem, once you have better FFI generate > bindings for GTK/QT/â¦ > This is not giving up. This is not fighting battles you cannot win. > > Plug Computer > Really? You have all the other places that need more resources and you > want to do even more. > > Now the things that aren't on your list: > > VM: > Better JIT, allocator, collector. No matter how good your VM is it's never > good enough and there's always useful stuff you can add like monitoring. > > #identityHash > It would certainly be nice to have more than 12 hash bits, especially form > a performance PoV. IIRC there was once talk of getting rid of compact > classes. I take an additional hash bit over an immutability bit any time. > > Infrastructure > If your tools and build infrastructure are holding you back fix them. I > would be quite happy if a year from now Pharo is exactly the same and the > only thing that changed is the infrastructure you use to build Pharo is way > better. I know Seaside sucks at this as well. > > Migration Support > Since you're changing quite a lot of things (SystemDictionary/**SmalltakImage, > file system, streams, â¦) it would be nice to have support to: > - tell the user where he uses deprecated code > - assist the user in migrating to new APIs > this can also help you migrate everything in Pharo to the new APIs. You > probably want to build on top of the rewrite engine of RB. Since you don't > have static types the migration can probably only done in a semi-automated > way presenting the user a list of possible matches and letting him select > the appropriate ones. The deprecation support has been discussed > previously. This is probably the only thing in this list that could be put > into research papers. > > Releases > I know Seaside sucks at this as well so this isn't a flame. To me as an > outsider the release process of Pharo is confusing. I find the release > process of Eclipse [2] [3] better. The main points are: > - One main release every year > - Two bugfix releases every year > - after the two bugfix releases a new main release is done and the old > main release becomes unsupported > The releases are date driven, not feature driven. The dates for the ga, rc > and milestone releases as well as feature and API freezes are set years in > advance. That has downsides. For example if your feature misses a deadline, > you have to wait for more than a year to see it in a release. But it makes > everything nicely planable. > > [1] http://www.innoq.com/soa/ws-**standards/poster/innoQ%20WS-** > Standards%20Poster%202007-02.**pdf<http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%…> > [2] http://wiki.eclipse.org/**Simultaneous_Release<http://wiki.eclipse.org/Simultaneous_Release> > [3] http://wiki.eclipse.org/**SimRel/Overview<http://wiki.eclipse.org/SimRel/Overview> > > Cheers > Philippe > > >

Feb. 6, 2012

Re: [Pharo-project] About linkedlist

by Nick Ager

Hi Stef, Thanks for the explanation frank > btw (did you dd it in the class comment because it would be gorgeous). > I learned something today so I'm happy. > Now what is the typical use case for such persistent structure? > > Stef Immutable data structures are used extensively in functional languages in which data structures are *im*mutable by default. One benefit of the approach is when multi-threading you don't need to synchronise changes to such structures or objects containing them. For example all Clojure's data-structures are immutable by default [1]. There's been a lot of interesting work on providing performance guarantees so that creating copies avoids scaling with linear time [2], while still having sensible access and iteration performance. [1] http://clojure.org/data_structures#Data%20Structures-Collections [2] http://clojure.org/functional_programming#Functional%20Programming--Immutab… Apologies if I'm stating the obvious Nick

Feb. 6, 2012

Re: [Pharo-project] About linkedlist

by Frank Shearar

On 5 February 2012 10:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks for the explanation frank > btw (did you dd it in the class comment because it would be gorgeous). > I learned something today so I'm happy. > Now what is the typical use case for such persistent structure? Indeed I made sure to write a decent class comment :) The use case is twofold: * any time you want to stop caring about whether you need to copy a collection or can safely pass it around (so avoiding the "foo copy addAll: bar; yourself" idiom) * any time you want to be able to undo changes to some structure. In particular, I wanted to add an "or unifier" to my unification library. (Unification is like bidirectional pattern matching. In particular, we build up an equivalence relation over the nodes in two structures. After that, if any partitions in the relation contain variables, we can construct a mapping from variables to concrete values, to give a most general unifier.) This would let me say "can X or Y unify against this thing?" - (Node left: (Leaf value: #x asVariable)) or: (Node right: (Leaf value: #x asVariable)) =? someRandomTree will * only do something useful if someRandomTree has exactly one child Leaf, and * will tell us what the value of that Leaf is, by telling us how to map from the variable called #x to that value. What I quickly found was that the unification algorithm - which used a normal, non-persistent (ephemeral) union-find - kept its state after attempting to unify the first disjunction clause. That meant that unifying the clause would sometimes fail. What I actually wanted was to be able to say * given some partial term relation U, * try unify the first clause to get a new term relation U1 * but if unification fails, start back with U and try calculate a new term relation U2 on the second clause's nodes Using a _persistent_ union-find lets me thus roll back or undo the term relation construction and revert to an older version. frank > > Stef > > On Feb 4, 2012, at 3:33 PM, Frank Shearar wrote: > >> On 3 February 2012 20:40, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> >>>>> >>>>> I wasn't sure what double-ended versus single-ended meant, and found some >>>>> answer at the obvious place [1] >>>>> which mentions Ada.Containers.Vectors is a dynamic array implementation >>>>> which seems consistent with C++ [2]. >>>>> While looking around I happened to bump into [3] which was too much for me >>>>> but may be of interest to anyone playing with data structres. Â Skimming this >>>>> shows it discussing efficiency of data structures in functional languages >>>>> together with lazy variants of imperative language data structures. Â Would >>>>> such apply to Smalltalk or is the object-oriented style of Smalltalk >>>>> considered imperative rather than functional? >>>> >>>> The standard tool set - OrderedCollection, Array, etc., are not >>>> functional at all - (myArray at: 1 put: 2) mutates myArray, - so I'd >>>> put them firmly on the "imperative" side of the fence. >>>> >>>> There's nothing stopping one from writing functional data structures - >>>> Levente Uzonyi's written some persistent data structures, as have I. >>>> ("Persistent" means you get new versions of a data structure; if you >>>> hang onto those old versions you can roll back your changes.) >>> >>> Can you explain a bit more Persistent? >> >> Sure! A persistent data structure is an _apparently_ immutable data >> structure: editing the structure returns you a _new_ structure. If you >> can modify only the latest version of the structure, it's >> _partially_persistent_; if you can edit any version it is >> _fully_persistent_. Of course "edit" here means "get a new collection >> representing the edit" >> >> For example, if you load the PersistentUnionFind package (no external >> dependencies) and print out this: >> >> | p p1 p2 p3 | >> p := PersistentCollection initially: #(1 2 3). >> p1 := p at: 1 put: 4. >> p2 := p1 at: 2 put: 5. >> p3 := p at: 3 put: 0. >> {p. p1. p2. p3.} collect: #asArray >> >> you get, with inline comments added: >> >> Â #("p:" #(1 2 3) "p1:" #(4 2 3) "p2:" #(4 5 3) "p3:" #(1 2 0)) >> >> So you can see the different versions of the original array: p1 is p >> plus one replacement; p2 is p plus two replacements (or equivalently >> p1 plus one replacement). >> >> You still get efficient access to the latest version, and the old >> versions describe themselves as a stack of undo operations - "I'm like >> the latest version, but with these changes". >> >> So if you just print out p1, you'll see: >> >> p1 printString. 'Ref(Diff(1, 4, Ref(Diff(3, 3, Ref(Arr(#(1 2 0)))))))' >> >> The series of Diffs tell you how to get from the latest version - p3 - >> to the version of p1: "take p3 ( #(1 2 0) ), at index 3 put a 3, and >> at index 1 put a 1". >> >> A Ref is a delegate: it allows your reference to something to stay the >> same even though the thing referenced changes. >> >> Internally, as you access the latest version of the Collection the >> structure rewrites itself: if it's pointing to a Diff it "reroots" >> itself. (This does have the issue that if you hang onto two versions >> of the collection and access each version alternately, the >> PersistentCollection will waste a lot of time constantly rerooting >> itself.) >> >> You can see then that keeping a reference to an old version allows you >> to undo arbitrary changes to the collection. >> >> PersistentUnionFind _should_ load cleanly into Pharo: if it doesn't, >> let me know and I'll fix it so it does. >> >> frank >> >>> Tx >>> >>> >>>> http://www.squeaksource.com/Nutcracker/ is my own play area for these >>>> sorts of structures - PersistentUnionFind looks like a functional data >>>> structure while internally massively using side effects. >>>> http://www.lshift.net/blog/2011/12/31/translating-a-persistent-union-find-f… >>>> has references to the original papers I used for my translation. >>>> >>>> Okasaki's book is really good reading, if a bit advanced. It also has >>>> a bunch of stuff beyond just showing functional data structures. (Note >>>> that the red-black tree implementation is _incomplete_ - he leaves >>>> deleting nodes as an exercise for the reader. (See >>>> http://matt.might.net/articles/red-black-delete/)) >>>> >>>> frank >>>> >>>>> [1] http://en.wikipedia.org/wiki/Double-ended_queue >>>>> [2] http://en.wikipedia.org/wiki/Sequence_container_%28C%2B%2B%29 >>>>> [3] http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf >>>>> >>>> >>> >>> >> > >

Feb. 6, 2012

[Pharo-project] ConfigurationOfSIXX status?

by Schwab,Wilhelm K

Does anyone know the status of the SIXX configuration. I can't get it to load. In general, what does it mean when Gofer doesn't? I hate to repeat myself, but silent failures are one of the worst things a computer can do, and I'm getting them (often). Bill

Feb. 6, 2012

Re: [Pharo-project] [update 1.4] #14314

by Lukas Renggli

> - there should be :D (I imagine it exactly like in eclipse, cmd-key pressed => underline all links and display a hand cursor onOver) > - telling morphic to do highlighting is a different story |-( > - right now you only get onDrag events in â although named onMove â I guess I will have to hack a bit :) > - right-click menus should start working again (they're currently slightly broken) > - we should have refactoring menus in there (rename instVar/args, push instvar...) Most of these things have been done in Helvetia. The next most useful thing after code navigation was on-the-fly Code Critics with the yellow wiggly underlines and Ctrl+1 instant-fix. Lukas -- Lukas Renggli www.lukas-renggli.ch

Feb. 6, 2012

[Pharo-project] Report from FOSDEM please! :)

by GÃ¶ran Krampe

...I want to hear how darn cool it was and how droves of new Smalltalkers got "reborn" :) regards, GÃ¶ran

Feb. 6, 2012

Re: [Pharo-project] [update 1.4] #14314

by Mariano Martinez Peck

On Mon, Feb 6, 2012 at 9:49 AM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > > On 2012-02-05, at 12:49, Sven Van Caekenberghe wrote: > > > > On 05 Feb 2012, at 11:27, StÃ©phane Ducasse wrote: > > > >> > >> 14314 > >> ----- > >> > >> - Issue 5233: Support Semantic Source Links. Thanks Camillo > Bruni. > >> http://code.google.com/p/pharo/issues/detail?id=5233 > >> > >> Now when you press command while clicking on a class name you jump to > the class :). > >> Same for the click on a method name and instance variable. > >> > >> Pay attention that this change should really be changed on windows and > linux. So please give us feedback. > >> Camillo will do a fix so that menu appears on click down versus click > up. > > > > Yes ! This is a supercool feature, really. Thx ! > > > > One remark though: shouldn't there be any kind of feedback, like > underlining the classname/methodname or a popup text ? > > > > Sven > > TODO: > > - there should be :D (I imagine it exactly like in eclipse, cmd-key > pressed => underline all links and display a hand cursor onOver) > that would be awesome :) > - telling morphic to do highlighting is a different story |-( > - right now you only get onDrag events in â although named onMove â I > guess I will have to hack a bit :) > - right-click menus should start working again (they're currently slightly > broken) > - we should have refactoring menus in there (rename instVar/args, push > instvar...) > > cami > -- Mariano http://marianopeck.wordpress.com

Feb. 6, 2012

Re: [Pharo-project] [update 1.4] #14314

by Camillo Bruni

On 2012-02-05, at 12:49, Sven Van Caekenberghe wrote: > > On 05 Feb 2012, at 11:27, StÃ©phane Ducasse wrote: > >> >> 14314 >> ----- >> >> - Issue 5233: Support Semantic Source Links. Thanks Camillo Bruni. >> http://code.google.com/p/pharo/issues/detail?id=5233 >> >> Now when you press command while clicking on a class name you jump to the class :). >> Same for the click on a method name and instance variable. >> >> Pay attention that this change should really be changed on windows and linux. So please give us feedback. >> Camillo will do a fix so that menu appears on click down versus click up. > > Yes ! This is a supercool feature, really. Thx ! > > One remark though: shouldn't there be any kind of feedback, like underlining the classname/methodname or a popup text ? > > Sven TODO: - there should be :D (I imagine it exactly like in eclipse, cmd-key pressed => underline all links and display a hand cursor onOver) - telling morphic to do highlighting is a different story |-( - right now you only get onDrag events in â although named onMove â I guess I will have to hack a bit :) - right-click menus should start working again (they're currently slightly broken) - we should have refactoring menus in there (rename instVar/args, push instvar...) cami

Feb. 6, 2012