- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Scamper revival

by laurent laffont

The goal is to use it for the new HelpSystem, to display images, layout easily, some colors. For browsing the web it's crap. Laurent Laffont 2010/2/27 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > I would much rather see a robust interface to an external browser, for > two reasons: (1) scamper was never terribly impressive; (2) Seaside testing. > > Bill > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *laurent > laffont > *Sent:* Friday, February 26, 2010 4:45 PM > *To:* An open mailing list to discuss any topics related to an open-source > Smalltalk > *Subject:* [Pharo-project] Scamper revival > > Hi, > > It's not stable, but it loads google :) > > Gofer new > squeaksource: 'LaurentLSandbox'; > package:'HTML'; > package:'Scamper'; > load. > Then: > > Scamper openOnUrl: 'http://www.google.com'. > > > I suppose there's a technique to replace all _ by := > > Laurent Laffont > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Igor Stasenko

On a second thought, i think this is not really necessary. Traits can be reformulated to be purely a method source holders, not holders of compiled methods. (And btw, this is actually true, due to the latest changes in traits, because of super sends issues and #methodClass), we only need to push it a little further and get rid of useless limitations. The point is, that all trait methods should _always_ be compiled in the scope of the class to which it applied. Because, for any variable name, which not declared explicitly in the method's scope, we can't tell anything about it, until we apply this method to the real class (See the Class>>bindingOf: ) This means that, even if you having the trait method: foo ^ Array new: 10 the binding of 'Array' variable may be different, depending on class where its installed. To check it, you can try following at home: Object subclass: #ZZZZ instanceVariableNames: '' classVariableNames: 'DD' poolDictionaries: '' category: 'ZZZZ' "add new pool variable" ZZZZ classPool at: #Array put: 10. "now add the method" array ^ Array and now evaluate the following: ZZZZ new array ------------- But what makes array ^ Array method any better than array ^ array := 10. in this regard? Nothing. So, why not drop the limitation, and instead of punishing developer for use undeclared vars in trait methods, punish him for use of undeclared variables, when he tries to apply the trait to concrete class, where all such var names should obtain meaning? Then, ultimately, what is the point in storing compiling methods in Trait (not for classes, where it applied). We could just check the syntax, but should not produce any CompiledMethod instances at all. What other problems i don't see here? On 27 February 2010 02:10, Stan Shepherd <stan.shepherd414(a)gmail.com> wrote: > > > Igor Stasenko wrote: >> >> One of the ways of introducing a stateful traits is changing the VM >> object format. >> > Sounds like it could be very powerful. > > As it happens, in the fork healing example, it's the very statelessness of > the traits that make it work so simply. By taking out the Â check for > statefulness when the method is moved to a trait, the trait will quite > happily address the several variables in its user classes. This then removes > any need for accessors, helper classes for state, initialization, or other > attempts to tame the beast. > > I wouldn't want to rely on it continuing to work in all conditions, but as a > step in a refactoring it seems very handy. > > ..Stan > -- > View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571553.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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.

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Stan Shepherd

Igor Stasenko wrote: > > One of the ways of introducing a stateful traits is changing the VM > object format. > Sounds like it could be very powerful. As it happens, in the fork healing example, it's the very statelessness of the traits that make it work so simply. By taking out the check for statefulness when the method is moved to a trait, the trait will quite happily address the several variables in its user classes. This then removes any need for accessors, helper classes for state, initialization, or other attempts to tame the beast. I wouldn't want to rely on it continuing to work in all conditions, but as a step in a refactoring it seems very handy. ..Stan -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571553.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 27, 2010

Re: [Pharo-project] Developing morphic apps with pharo - sorting wheat from chaff

by Richard Durr

Maybe the Brazil part of Newspeak is an option? On Fri, Feb 26, 2010 at 4:34 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Why can't this stuff be *simple* and *beautiful*? > > Â Â Â Â Marcus >

Feb. 26, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Stan Shepherd

Lukas Renggli wrote: > >>> To test out the possibilities of using traits for refactoring, I had a >>> go at >>> rationalising OmniBrowser/OmniBrowser2. >> >> Good! I like the idea to have traits shared between browser. > > What is the benefit for the maintainers of the two browser? > I should imagine none ;) I wouldn't advocate this approach for two projects that are going to remain separate. While there would be a small saving in double handling bugs in the common methods, as in http://code.google.com/p/pharo/issues/detail?id=1887&can=1&q=copy&sort=-id&… Issue 1887 it wouldn't outweigh the hassle. > To me this doesn't make any sense: the Traits themselves don't have > any meaning, they are just there to share code that randomly matches > in both implementations. I imagine that changing a trait for one > browser almost certainly breaks something in the other browser? Who > ensures that the trait use is kept in sync between the two > implementations? How can I avoid to accidentally leak code from one > browser into the other one? What happens if one of the browsers > reactors its class hierarchy? > > To me this all looks like a lot more work, more things to maintain and > think about. > Again, I wouldn't advocate this for two actively, separately maintained, packages. But in the hypothetical where you did try this: > changing a trait for one browser almost certainly breaks something in the > other browser I think if you wanted the methods no longer to be the same, you would implement the change back in your version of the class. The other user would see no change. > Who ensures that the trait use is kept in sync between the two > implementations? How can I avoid to accidentally leak code from one > browser into the other one? The person who made any mod would have the choice of doing so unilaterally, in the local class, or of negotiating a common change. You do get prompted to ask whether you want to change the trait or make the change locally, but you could accidentally change the trait by clicking the wrong option. > What happens if one of the browsers reactors its class hierarchy? > Then clearly all bets would be off, because they are no longer common in that sense. The refactoring version would repatriate its traits into methods and go from there. I could see the trait approach being useful in the following circumstances: The two versions decide to get together and heal the fork. Taking the functionality apart into traits helps to identify what is different, what actually needs to be different, and how it can be moved to non-interfering places. or Before the fork takes place, the two versions decide that forking is necessary, but they wish to retain as much commonality as possible. Cheers, ...Stan -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571540.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 26, 2010

Re: [Pharo-project] Streams. Status and where to go?

by Richard Durr

So what speaks against using VisualWorks' Xtreams? http://www.cincomsmalltalk.com/blog/blogView?entry=3444278480&printTitle=Sm… On Fri, Feb 26, 2010 at 11:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 February 2010 21:30, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>> On 26 February 2010 18:59, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>>>> Hello, Nicolas. >>>> >>>> Hi igor. >>>> You should load it in trunk. >>>> >>> Ah, i think my image is a bit outdated then. >>> >>>>> I want to try it out. >>>>> I tried to load it (XTream-Core) into my image, and it bug me about >>>>> unresolved dependencies: >>>>> ---- >>>>> This package depends on the following classes: >>>>> Â ByteTextConverter >>>>> You must resolve these dependencies before you will be able to load >>>>> these definitions: >>>>> Â ByteTextConverter>>nextFromXtream: >>>>> Â ByteTextConverter>>nextPut:toXtream: >>>>> Â ByteTextConverter>>readInto:startingAt:count:fromXtream: >>>>> ---- >>>>> I ignored these warnings, pressing continue, and here what it warns >>>>> about in my trunk image: >>>>> >>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Map is Undeclared) >>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Encodings is Undeclared) >>>>> TextConverter>>readInto:startingAt:count:fromXtream: (latin1Map is Undeclared) >>>>> >>>>> Is ByteTextConverter a Pharo-specific class? >>>>> >>>> >>>> This is a refactoring of TextConverter I made in trunk. >>>> Pharo did the same before me (it comes from Sophie), but I missed it >>>> unfortunately... >>>> >>>>> If you seen my previous message, i think you noticed that >>>>> XXXTextConverter is abdominations (IMO), and should be reimplemented >>>>> as a wrapping-streams instead. >>>>> Would you be willing to change that in XStreams? I mean implementing a >>>>> conversion streams model, which can wrap around any other stream, >>>>> like: >>>>> >>>>> myStream := UTFReaderStream on: otherStream. >>>>> myString := myStream contents. >>>>> >>>>> or using other way: >>>>> >>>>> myString := (someBaseStream wrapWith: UTFReaderStream) contents. >>>>> >>>>> or.. >>>>> myDecodedString := (someBaseStream wrapWith: (DecodingStreams >>>>> decoderFor: myEncoding) contents. >>>>> >>>>> That's would be much nicer than using converters. >>>> >>>> Currently, I have a ConverterReadXtream and a ConverterWriteXtream >>>> which are stream wrappers. >>>> They use old TextConverter to do the real job, but I agree, a full >>>> rewrite of this one is needed. >>>> However, I would like to keep these two layers for Stream composition: >>>> - the generic converter stream >>>> - the conversion algorithm >>>> >>> >>> Why? >>> In your implementation you already added the >>> readInto: aCollection startingAt: startIndex count: anInteger >>> and >>> next: count into: aString startingAt: startIndex >>> into converters, which makes them even more like streams. >>> >> >> Yes, you may be right. >> Maybe my ratio innovating/reusing was a bit low :) >> >>> So, what stopping you from making an abstract, generic XtreamWrapper class, >>> and then a number of subclasses Â (LatinConversionStream , >>> UnicodeConversionStream etc), >> >> Yes, that's possible. But it's already what ConverterReadXtream and >> ConverterWriteXtream are. >> > > I suggesting to use a following hierarchy > > Xtream -> XtreamWrapper -> ConverterXtream -> (bunch of subclasses) > > or just > > Xtream -> XtreamWrapper -> (bunch of subclasses) > > since i don't think there a lot of specific behavior in > ConverterXtream worth creating a separate class. > But maybe i'm wrong. > >>> as well as BufferedWrapper? >>> >> >> BufferedReadXtream and BufferedWriteXtream already are generic. It's >> just that I have separated read and write... >> So you will find ReadXtream>>buffered >> Â Â Â Â ^(BufferedReadXtream new) >> Â Â Â Â Â Â Â Â contentsSpecies: self contentsSpecies bufferSize: self preferredBufferSize; >> Â Â Â Â Â Â Â Â source: self >> >> Or do you mean a single Buffer for read/write ? >> That would look more like original VW I think. >> > > obviously, if you reading and writing to same stream , you should take > care of keeping any buffered i/o in sync. > The #buffered can decide what kind of stream to create > self isWritable ifTrue: [ create R/W wrapper ] ifFalse: [ create R/O wrapper ] > > this is , of course if you promote #buffered to Xtream class. Which i > think worthful thing. > >>> So, it will cost us 1 less message dispatch in >>> a := stream next. >>> >>> In your model you having: >>> >>> (converter stream) -> (converter) -> basic stream >>> >>> while if using wrapper it will be just: >>> (converter wrapper) -> basic stream >>> >> >> I must re-think why I made this decision of additional indirection... >> Maybe it was just reusing... >> > > I think this is just about reuse. But as i shown in > UFT8TextConverter>>nextFromStream: > its in addition to extra dispatch, using a characters instead of > bytes, which can be avoided > if you wrap the stream to be converted and tell it to work in binary > mode, since your wrapper are in control. > >>> >>>> Though current XTream is a quick hack reusing Yoshiki TextConverter, >>>> it already demonstrates possible gains coming from buffering. >>>> The speed comes from,applying utf8ToSqueak, squeakToUtf8 trick: copy >>>> large ASCII encoded portions verbatim. >>>> This works very well with squeak source because 99,99% of characters are ASCII. >>>> >>>>> >>>>> Wrappers is more flexible comparing to TextConverters, since they are >>>>> not obliged to convert to/from text-based collections only. >>>>> For example, we can use same API for wrapping with ZIP stream: >>>>> >>>>> myUnpackedData := (someBaseStream wrapWith: ZIPReaderStream) contents. >>>>> >>>>> and many other (ab)uses.. Like reading changeset chunks: >>>>> >>>>> nextChunk := (fileStream wrapWith: ChunkReaderStream) next. >>>>> >>>> >>>> Yes, that fits my intentions. >>>> What I want is to preserve buffered operations along the chain, and >>>> avoid byte-by-byte conversions when possible. >>>> >>> >>> Buffering is just a wrapper. Btw, again, why you don't providing a >>> generic wrapper class which everyone can subclass from? >>> >>> bufferedStream := anyStreamClass buffered >>> >>> (buffered wrapper) -> (anyStreamClass) >>> >> >> See above, it's just split in BufferedRead/WriteXtream >> >> Or see the example (a bit heavy) >> Â tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles at: 2) name) >> Â Â Â readXtream ascii buffered decodeWith: (UTF8TextConverter new >> installLineEndConvention: nil)) buffered. >> > > yes. its a bit heavy, but this is a way how one should build a chains > of streams. > Except that there should be only streams in chain, no non-stream > converters in between :) > >> >>> i don't see where else you should care of buffering explicitly in >>> anyStreamClass. >>> >>> And, how you can avoid byte-by-byte conversion in utf8? It should >>> iterate over bytes to determine the characters anyways. >> >> True, it is faster because you scan fast with a primitive, >> then copy a whole chunk with replaceFrom:to:with:startingAt: primitive >> >> Of course, if you handle some cyrillic files, then this strategy won't >> be efficient. It just work in ASCII dominated files. >> UTF8 itself would not be an optimal choice for cyrillic anyway... >> > I prefer to use UFT8 nowadays, instead of old rubbish encodings, which > is many :) > >>> But sure thing, nothing prevents you from buffering things in a way like: >>> >>> reader := anyStream buffered wrapWith: UTF8Reader. >>> >> >> My above example is just equivalent to: >> >> reader := (anyStream buffered wrapWith: UTF8Reader) buffered. >> >> Then even if I use reader next, a whole buffer of UTF8 is converted >> (presumably by large chunks) >> > > Right, nobody says that its not possible to do double-buffering. > First, by wrapping an original stream (presumably file-based) > and second - an output of utf8 converter. > > [snip] > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 26, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Igor Stasenko

One of the ways of introducing a stateful traits is changing the VM object format. There is a bits in object's header reserved for identity hash. Instead of putting the identify hash value there, we could use it to indicate if given object has additional arbitrary slots following the object contents: <header> <ivar1> ... <ivarN> <variableVar1> ... <variableVarM> <key1><value1> <key2><value2> ... <keyK><valueK> so, these keyN->valueN forming a dictionary of key/value pairs, which can be accessed using new primitives #slotAt: and #sloatAt:put: slot allocaiton can be expressed as: newObject := object copyWithSlot: key value: value. object becomeForward: newObject. (except that this is done by VM primitively). Once slots is allocated, object size is not grows anymore (so there are no overhead) and as bonus, you getting a way to attach any additional state to virtually any objects (except smallints) , for any purposes. Identity hash is become slower, but only at first hashing attempt. (slotAt: #identityHash put: value) But as benefit, we could use any object (or just 31 bit small integer) for hash values, which will increase the hashing quality considerably. So, it is a question, what will be faster, especially for large dictionaries. Obviously, then traits free to use this to keep own state, without any extra demands from classes where it installed: foo ^ self slotAt: #foo foo: value self slotAt: #foo put: value Also, I think that with such extension, we might expect a considerable speed boost for Magma OODB, which can use additional slot for marking objects by own ids, as well as for marking object dirty, instead of maintaining a huge and ineffective IdentityDictionaries to track the objects state. -- Best regards, Igor Stasenko AKA sig.

Feb. 26, 2010

Re: [Pharo-project] Scamper revival

by Schwab,Wilhelm K

I would much rather see a robust interface to an external browser, for two reasons: (1) scamper was never terribly impressive; (2) Seaside testing. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of laurent laffont Sent: Friday, February 26, 2010 4:45 PM To: An open mailing list to discuss any topics related to an open-source Smalltalk Subject: [Pharo-project] Scamper revival Hi, It's not stable, but it loads google :) Gofer new squeaksource: 'LaurentLSandbox'; package:'HTML'; package:'Scamper'; load. Then: Scamper openOnUrl: 'http://www.google.com'. I suppose there's a technique to replace all _ by := Laurent Laffont

Feb. 26, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Stan Shepherd

StÃ©phane Ducasse wrote: > > stan > > as one of the trait "guy" we should consider that > - probably what we got can be improved > for example I was discussing about the implementation in javascript and > tom is proposing to have a > a shallow rename of methods + adding a requirement instead of an alias > (this way you can limit the interface explosion) > > - I did not like the stateful traits even if this is my idea. > what we tried to do what do make sure that we do not have to recompile > the code in each user. > Now since methods are not shared (I'm sad about that) between trait user > then we could recompile > the methods for each user and users could have different states and state > layout. > > - for state the question in initialize: how do we initialize trait state > in the composite in an elegant way > in ambianttalk we get > T1>>initialize > T2>>initialize > C > T1 initialize -> T1init > T2 initialize -> T2init > and initialize > self T1init. > self T2init > > - for Plug like delegatee we are working with people from KUL on > understanding a kind of subobject trait based approach. > We will send information when the paper is published. But you can read > the ecoop paper of marko van dooren > > > - Did you check the solution proposed in VW to have state in traits? > I do not remember it (shame on my weak memory) > No, I didn't get to that one. >> >> To test out the possibilities of using traits for refactoring, I had a go >> at >> rationalising OmniBrowser/OmniBrowser2. > > Good! I like the idea to have traits shared between browser. > It's possible to try out the 'semi-healed' version. In a new image: Gofer new squeaksource: 'MetacelloRepository'; package:'ConfigurationOfHealer'; load. ((Smalltalk at: #ConfigurationOfHealedOmniBrowser) project version: '0.6-baseline') load . Not recommended on your production system. > > This showed up that it appears to be possible to use the current traits > implementation in a 'quasi-stateful' manner. that is, you can directly > address the variables of a trait's 'hosting' class. This is rather > contrary > to my previous understanding of stateless traits. Is this normal > behaviour? > > I've written up the details here. > > http://neat-sheet.com/development-blog.html/ > > ...Stan -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571472.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 26, 2010

[Pharo-project] Scamper revival

by Torsten Bergmann

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

Feb. 26, 2010