- Pharo-dev - lists.pharo.org

Re: [Pharo-project] new Cog VMs
by mkobetic＠gmail.com Jan. 3, 2011

Jan. 3, 2011

"Eliot Miranda"<eliot.miranda(a)gmail.com> wrote: > so find new VMs in > VM.r2341/<http://www.mirandabanda.org/files/Cog/VM/VM.r2341/>. Yup, much better on my end. Thanks! Martin

1 0

[Pharo-project] [update 1.2] #12291
by StÃ©phane Ducasse Jan. 2, 2011

Jan. 2, 2011

12291 ----- - Issue 3502: DNU while parsing. Thanks Alain Plantec. - Issue 3224: Migrating MethodReference to MethodReferenceWithSource. Part one. Thanks Benjamin van Ryseghem Stef

1 0

[Pharo-project] Issue 3404 in pharo: Recent messages should be able to work on a limited subset of the recently changed methods
by pharo＠googlecode.com Jan. 2, 2011

Jan. 2, 2011

Status: Accepted Owner: stephane.ducasse CC: Benjamin.VanRyseghem.Pharo Labels: Milestone-1.2 New issue 3404 by stephane.ducasse: Recent messages should be able to work on a limited subset of the recently changed methods http://code.google.com/p/pharo/issues/detail?id=3404 Benjamin RecentMessages is terribly slow and it should also take a lot of spaces when we have a lot of changes. Then when I selected version + by version I do not understand what it means and when I press browse I got an error.

1 2

[Pharo-project] Issue 3502 in pharo: DNU while parsing
by pharo＠googlecode.com Jan. 2, 2011

Jan. 2, 2011

Status: Accepted Owner: Torsten....@astares.de New issue 3502 by Torsten....@astares.de: DNU while parsing http://code.google.com/p/pharo/issues/detail?id=3502 ($A to: $Z) do: [:each | Transcript show: '|*'; show: each asString; show: '>Index: '; show: each asString; show: '*'; ] gives a cascade error in squeak and a DNU in recent Pharo: TextMorphForEditView(Object)>>doesNotUnderstand: #notify:at:in: Receiver: a TextMorphForEditView(284950528) Arguments and temporary variables: aMessage: notify: 'Cascade expected ->' at: 131 in: a ReadWriteStream '($A to: ...etc... exception: MessageNotUnderstood: TextMorphForEditView>>notify:at:in: resumeValue: nil Receiver's instance variables: bounds: 0@0 corner: 432@114 owner: a TransformMorph(182190080) submorphs: #() fullBounds: 0@0 corner: 432@114 color: Color black extension: a MorphExtension (680787968) [other: (blinkStart -> 14517886) (myDe...etc... borderWidth: 0 borderColor: Color black textStyle: a TextStyle Bitmap DejaVu Sans 9 text: a Text for '($A to: $Z) do: [:each | Transcript show: ''|*''; show: ea...etc... wrapFlag: true paragraph: a MultiNewParagraph editor: a SmalltalkEditor container: nil predecessor: nil successor: nil backgroundColor: nil margins: nil editView: a PluggableTextMorph(123469824) acceptOnCR: false Parser>>notify:at: Receiver: a Parser Arguments and temporary variables: string: 'Cascade expected' location: 131 Receiver's instance variables: source: a ReadWriteStream '($A to: $Z) do: [:each | Transcript show: ''|*''; ...etc... mark: 130 hereChar: Character arrowUp aheadChar: Character arrowUp token: #'' tokenType: #doIt currentComment: nil buffer: a WriteStream '*' typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... here: #']' hereType: #rightBracket hereMark: 131 hereEnd: 130 prevMark: 127 prevEnd: 127 encoder: {an EncoderForV3PlusClosures} requestor: a TextMorphForEditView(284950528) parseNode: {Transcript} failBlock: [^ failBlock value] requestorOffset: 0 tempsMark: 1 doitFlag: true properties: an AdditionalMethodState category: nil Parser>>expected: Receiver: a Parser Arguments and temporary variables: aString: 'Cascade' Receiver's instance variables: source: a ReadWriteStream '($A to: $Z) do: [:each | Transcript show: ''|*''; ...etc... mark: 130 hereChar: Character arrowUp aheadChar: Character arrowUp token: #'' tokenType: #doIt currentComment: nil buffer: a WriteStream '*' typeTable: #(#xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xBinary #xB...etc... here: #']' hereType: #rightBracket hereMark: 131 hereEnd: 130 prevMark: 127 prevEnd: 127 encoder: {an EncoderForV3PlusClosures} requestor: a TextMorphForEditView(284950528) parseNode: {Transcript} failBlock: [^ failBlock value] requestorOffset: 0 tempsMark: 1 doitFlag: true properties: an AdditionalMethodState category: nil

1 4

[Pharo-project] source.lukas-renggli.ch is down
by Torsten Bergmann Jan. 2, 2011

Jan. 2, 2011

and it is one of the reasons why the hudson build fails :( https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastFailedBui… Even when Lukas restores the server it would be good to use community controlled squeaksource servers in the future instead of personal servers (the "truck factor" - you know) Bye T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

8 11

[Pharo-project] source.lukas-renggli.ch is down
by Torsten Bergmann Jan. 2, 2011

Jan. 2, 2011

>Looks like it takes 1 or 2 weeks more, weeks? Would'nt it be possible to upload the stuff to a repo on squeaksource.com and switch the repository so we are not dependent on your private server? Thanks Torsten -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

1 0

[Pharo-project] An intuitive (or screwed) #copyFrom:
by Sebastian Sastre Jan. 2, 2011

Jan. 2, 2011

('if this isn''t broken' copyFrom: 15) ~= 'broken' ifTrue:['this is screwed'] ifFalse:['this is intuitive'] Evaluate that in any Pharo workspace and it will show you. Reported here. Status? invalid Came on guys. Really? I ask because, if so, situation goes like this: A. we think again and decide to do the right thing or we go with the alternative which is B. we leave it as invalid, as it is right now, and 1. we mislead even to smalltalkers not familiarized to squeak/pharo 2. we rationalize some clever way to see it as a feature even if it will mislead everybody (even ourselves in a hurry) 3. we lay a foundation to lightly use protocol that is typically used in collections (to do dangerous things like instVar manipulation) 4. we break encapsulation and manipulate extremely primitive things in a common sounding selector. 5. we work harder on trying to give the impression that we're leaving it like that because we're smarter than the confused people that tried to use it (proving to them that we're dumb) 6. we get involved in an unnecessarily complicated way of thinking that will complicate unnecessarily our future (guaranteed) 7. we learn how to maintain a screwed attitude in front of people trying to use intuition when using pharo 8. we stay comfortable (on the wrong foundation and for the wrong reasons) That would leave us with this question in the table: what is compatible with the Pharo's mission? is it A or B?

8 15

Re: [Pharo-project] Xtreams updates: positioning, slicing and stitching
by mkobetic＠gmail.com Jan. 2, 2011

Jan. 2, 2011

"Francisco Ortiz PeÃ±aloza"<patchinko(a)gmail.com> wrote: > Hi Martin, thanks i'll try it later! > > It would help if you could provide a Metacello configuration for it. Yes, something like that is clearly needed, but I'm still finding my way around the environment. However at the moment Xtreams don't have any prerequisites, so something like the gofer expression below should do it (you can skip the tests if you want). Gofer new squeaksource: 'Xtreams'; package: 'Xtreams-VWCompatible'; package: 'Xtreams-Core'; package: 'Xtreams-Terminals'; package: 'Xtreams-Transforms'; package: 'Xtreams-Substreams'; package: 'Xtreams-SqueakExternals'; package: 'Xtreams-SqueakTextConverter'; package: 'Xtreams-CoreTests'; package: 'Xtreams-TerminalTests'; package: 'Xtreams-TransformsTests'; package: 'Xtreams-SubstreamsTests'; load But we'll likely want a metacello config eventually, especially when we bring in FFI for calling things like zlib and libcrypto. Cheers, Martin

1 0

[Pharo-project] Xtreams updates: positioning, slicing and stitching
by mkobetic＠gmail.com Jan. 2, 2011

Jan. 2, 2011

I updated the Xtreams port (http://www.squeaksource.com/Xtreams) over the holidays to catch up with the state on VW side. The primary changes are updates/fixes of the positioning API and a cleanup/extension of the slicing API. The slicers are replaced by much simpler #slicing setup and the inverse, #stitching, was added (the updated documentation can be found in the usual place: http://code.google.com/p/xtreams/wiki/Substreams) More details on the changes below. Enjoy, Martin Positioning updates: * ++/--/+=/-=/position: now return the argument instead of self * they all also skip as far as they can raising Incomplete with the count of the actual amount skipped * this means that the positioning wrapper will advance as far forward as it needs to satisfy the request, in case of -= it means it will advance all the way to the end of the underlying stream. * similarly asking a positioning wrapper for length or available will make it advance to the end * in the other direction, positioning wrapper can't skip past the beginning of its buffer, so if the buffer window moves forward, so does the absolute position; position 0 is always the beginning of the buffer, whereever it is at any given moment * also extended ++ and -- to call the other if the argument is negative (it helps with implementation of the others) All read/write/positioning calls except put:/get/read: now consistently return element counts so that one can use a computation as an argument and then obtain the actual number in response. This simplifies common patterns like: actual := [ stream ++ (x max: y) ] on: Incomplete do: [ :ex | ex count ]. instead of: actual := x max: y. [ stream ++ actual ] on: Incomplete do: [ :ex | actual := ex count ]. Slicing/Stitching updates: Replacing all the -er: slicer creation methods with the new #slicing and adding complementary #stitching. * #slicing is sent to a substream "prototype" and clones it when next slice is needed, e.g. (stream limiting: 3) slicing * #stitching is sent to a read stream of streams and makes it look like one continuous stream [ stream limiting: stream get ] reading stitching * stitching replaces the experimental proto and concatentation streams * ReadStream>>, is now implemented with stitching too

2 1

Jan. 1, 2011

Hi All (cross-posted squeak and pharo), I'm more and more in need for some graph lib in smalltalk. I need graphs to implement special bayesian networks (specific inference mechanisms which aren't probabilistic) and also influence diagrams [1], and maybe in the future, reliablity tools (markov chains, petri nets, ...)... Do you know any existing smalltalk (open source) projects for graphs? I've only found [2] and [3] from 2005 but don't know them (they don't feel as generic as I would expect). If not, do you know any open-source projects outside of Smalltalk that I may look at ? I've found BGL (C++) [3] which was ported in Ruby (RGL) [4]. Does some of you know this lib ? Do you think it would be interesting to have an equivalent in Smalltalk ? As usual, any comments/advises would be greatly appreciated ;-) ? Cheers, CÃ©drick [1] http://en.wikipedia.org/wiki/Influence_diagram [2] http://www.squeaksource.com/Graph [3] http://www.squeaksource.com/DynaGraph.html [4] http://www.boost.org/doc/libs/1_42_0/libs/graph/doc/index.html [5] http://rgl.rubyforge.org/rgl/index.html

11 26