- Pharo-dev - lists.pharo.org

[Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.412.mcz]
by Miguel Enrique CobÃ¡ Martinez Feb. 27, 2010

Feb. 27, 2010

This can be useful too. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

2 1

[Pharo-project] We should run + fix the tests in 1.1
by StÃ©phane Ducasse Feb. 27, 2010

Feb. 27, 2010

... testserver, where are you?

5 8

[Pharo-project] Scamper revival
by Torsten Bergmann Feb. 26, 2010

Feb. 26, 2010

Nice. If this is cleaned up we can use it in the help system. Thx T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

1 0

[Pharo-project] Few more words about Xtreams
by Igor Stasenko Feb. 26, 2010

Feb. 26, 2010

a) A BufferedXtream can be implemented ultimately as a wrapper stream, so any stream can be buffered , using Xtream>>buffered ^ self buffered: self preferredBufferSize Xtream>>buffered: aBufferSize ^ (self wrapWith: BufferedXtream) bufferSize: aBufferSize Xtream>>preferredBufferSize ^ 1024 I think there should be an abstract WrapperXtream, from which you can inherit various kinds of wrappers, like buffering, conversion etc etc. b) An ascii/binary mode should be deprecated. The rationale is: generic streams, as well as Collections can't say anything about nature of elements they working with. It could be anyting, like stream of collections, or stream of arbitrary objects. Introducing modes at such basic level implying that all streams should support either of them, and adding unwanted limiting factors and complexity. Its not a problem for more specific streams (like file/socket based ones) to implement these modes (or any other modes) in more robust manner. But i strongly suggesting to not introduce any modes in base class(es). Moreover, a different streams, potentially could support many various modes they like (compressed, encrypted etc etc). Marking out ascii/binary modes seems like a discrimination. But, for backwards compatibility, we could use wrappers to support these modes: Xtream>>ascii ^ self wrapWith: AsciiWrapper AsciiWrapper>>ascii ^ self and by analogy: Xtream>>binary ^ self wrapWith: BinaryWrapper BinaryWrapper>>binary ^ self this gives us a freedom for any streams to not care about supporting these modes explicitly, and in case if they care, they could implement these messages differently. c) species. A use of #contentsSpecies again, introducing a limiting factor, suggesting that all stream elements is going to be of same kind which could be put into special collection, which can hold only elements of specific kind like ByteArray or String. This message used primarily in conjunction with #readInto:startingAt:count: and #next:putAll:startingAt: for batch reads/writes which heavily depending on passing right collection type (you can't pass OrderedCollection or Set ;). My own preference is not _asking_ stream (or collection) for species of its element, but tell it to allocate the buffer (collection) of the kind it prefers , with given size. I.e. instead of: myBuffer := stream contentsSpecies ofSize: 1000. use: myBuffer := stream allocateBufferOfSize: 1000. Then, in most cases, you (as user) would never want to know the species of elements for a stream, and should not care about allocating them and knowing their class! This is one of the patterns i found more flexible and trying to stick with it everywhere i can. Instead of using: someClass := object fooClass. and then, somewhere use: thing := someClass new. i using: thing := object newThing. Because, by answering a class, you losing a control of the creation and proper initialization of these instances and by putting this responsibility onto user, obviously you opening a space for errors. A simple example, suppose you want to build a tree. As usual, you giving the user a way to create new nodes, by exposing the class he should use to create them: TreeNode>>nodeClass ^ TreeNode now, a user, to create a subnode should do things like: newNode := node nodeClass new. newNode parent: node. While, if you just give a simple #newChild TreeNode>>newChild ^ self class new parent: self then, user won't care about proper initialization and write just: newNode := node newChild. which is more concise, not requires to use intermediate value (node class) and much more error safe. -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] Source code management - my vision. (Was: Re: Why a package management system)
by Igor Stasenko Feb. 26, 2010

Feb. 26, 2010

Since Goran mentioned DeltaStreams, i'd like to share one of my ideas, which came into my mind, when i complete coding the method trailers. I made a method trailers open for future extensions. A first step would be to introduce an abstract 'source management' layer, which will be responsible for delivering a method's and classes sources from some abstract data source. The next step is actually implement such data sources. So, the idea is to abandon hardwiring with .sources and .changes files. What new opportunities it gives to us? Suppose that instead of storing sources into file, you putting them directly to database , such as CouchDB (yes! :). Now if you imagine that anyone could access to this database on some public location, this means that we automagically made a source code exchange hub, and could do a very cool things with it. Suppose that ALL source code is put into a single database. Now different users creating own accounts and makind own 'forks' from original. What we getting is a number of update streams (methods, doits etc etc), which lying in those databases, and if one user wants to load/merge code from one of the sources he simply points to it and it get loaded into his image. We could organize things very closely to what github currently is: everyone could create any number of new projects, or forks of existing ones. Freely exchange the code, do a cherry picking etc etc. And what is most important, that with such organization you can track any methods, classes in the image and their evolutionary history back to its origin. As well as, you can query database, how an when a concrete method/class get deleted (everything is recorded, not just current state). Also, it would allow us to manipulate the code at the lowest level of granularity (individual methods/classes/doits, same as DS does), not at a package level. There are a lot of synergy with DeltaStreams - it could serve as an 'offline' format, in same way as git storing the files locally, but can reconnect with remote storage (which can be a public database). One of the things, which could be made is to allow stashing/popping code from stash. Suppose two projects started from a single starting point (Squeak 3.9). Now suppose that by clicking a single button you could get either trunk image, or Pharo 1.0 image. But that's not all! With DeltaStreams, you could then click once more, and revert things back from , say Pharo 1.0 to trunk or vice versa :) Of course it would be stupid to do things at such large scale, but if we put some common 'root' stuff into database, then we could very easily track all changes & compare them. This would make cherry picking and code exchange much more easier. This could get us on the next level of code management and system organization and organization of community efforts. 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se>: > Hi! > > GermÃ¡n Arduino wrote: >> Hi GÃ¶ran: >> >> Sorry by my intromision here, but want to say somethings :) >> >> 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se <mailto:goran@krampe.se>> > [SNIP] >> Â Â What I have seen so far in Metacello is indeed nothing new - the >> Â Â senarios and discussions about dependencies etc go loooong way back. >> >> >> I'm on Squeak from old 3.2 times. And yes, a lot of discussions about >> packages, >> etc, but only discussions on most of cases. I think Metacello solves the >> dependencies >> questions very well and the other tools not (with exception of Universes >> probably, but >> abandoned now). Also Metacello provides all the features explained on >> the excellent >> mail of Torsten, assuring that the configurations will work with the >> time not breaking >> stuffs. >> >> The solution of using Metacello+Monticello is, imho, very simple, easy >> and productive >> and is here, available to us. :) > > I never claimed otherwise! I am just saying that there is nothing new - > and frankly, though I admit not having read carefully, I didn't find the > example so... impressive. Perhaps I need to read it again. > > Again though - I am not saying anything negative about Metacello. > > [SNIP] >> Â Â Anyway, "common exchange mechanism" - I am working on Deltastreams which >> Â Â I even presented at Brest, though unfortunately colliding with the >> Â Â Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY >> Â Â this problem (fork interchange), and it was born in 2007: >> >> Â Â http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… >> >> Â Â I and Igor are the ones working on it - and after Brest we have had very >> Â Â little time to move it forward. I still think it is a very important >> Â Â piece of the puzzle though. >> >> But Deltastreams are ready to use on production systems? > > Nope, not yet, although very close. But since the topic came up I wanted > to mention it. But AFAIK there is no other tool/project aimed at that > use case. Again, I may be wrong :) > > regards, GÃ¶ran > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

5 7

[Pharo-project] [update 1.1] #11236
by Marcus Denker Feb. 25, 2010

Feb. 25, 2010

11236 ----- Issue 1864: ScriptLoader cleanup scripts leave non-Empy Unamed chagenset Issue 1964: cycle cleaning: some method need to be moved between packages... Issue 2049: catchall for unsent message removal -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Thread UI
by Alexandre Bergel Feb. 25, 2010

Feb. 25, 2010

Dear List, I am extending the current set of Mondrian tests. I would like to force some system window to appear on the screen in order to properly test the size of its composing morphs. However, I do not know how to effectively make the morph show up on the screen in a test. For example, consider the following test with a contrived situation: testDummy | morph c | morph := Morph new openInWorld. c := Display colorAt: 0@0. morph delete. self assert: c = morph color. If I run the test from a test runner, it will fail. However, if I open a debugger and do a step by step, c = morph color is true. I guess the problem is that the morph is not actually displayed, since the UI thread does not have the hand. Any idea how to force this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 4

[Pharo-project] how to remove World?
by Esteban Lorenzano Feb. 25, 2010

Feb. 25, 2010

Hi, I want to prevent squeak to load the world morph... it is for a process running on background, anyway, and I want to prevent the time taken to draw the main window... so, I tried some simple things like: Smalltalk at: World put: nil. but that doesn't work... so, any idea? Thanks, Esteban

7 13

[Pharo-project] Diff tools
by GARY CHAMBERS Feb. 25, 2010

Feb. 25, 2010

New version on SqueakSource Polymorph-Tools-Diff-gvc.20. Descriptions added and small bug fix for merge tool (selecting next conflict now ignores "resolved" conflicts). Merge and select incoming for each conflict to load. Regards, Gary

4 9

[Pharo-project] [update 1.1] #11231
by Marcus Denker Feb. 25, 2010

Feb. 25, 2010

... late announce: - Issue 2053: New enh for polymorph widgets - Issue 2056: SmalltalkImage>>windowSystemName - Issue 2060: deprecate Number class>>#readExactlyFrom:'. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0