November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] NewInspector does not work well with delegated collections

by Mariano Martinez Peck

On Mon, Nov 29, 2010 at 9:38 PM, jaayer <jaayer(a)zoho.com> wrote: > Enclosed is a fileout of a sample collection named DelegatedSet that works > by delegating to an instance of Set stored in an instance variable. It > implements the basic protocol Collection requires, including #add:, > #remove:ifAbsent: and #do: as well as some additional messages, all through > delegation. Create an instance of it and then inspect that instance with > NewInsepctor, and you will notice the "Elements" item does not work. Nothing > happens when you click it. To inspect the elements, you need to click "set," > the instance variable containing the Set, and then inspect that object > further. Apparently, unless you override one or more messages under the > extension category *Newinspector, NewInspector will not know how to inspect > your collection properly. Worse, as soon as you do implement those methods, > unless you change their category, they will now be considered part of the > *Newinspector package rather than the package your collection belongs to and > will not be saved along with the collection. > > I think at a minimum, any collection understanding #do: and #size should be > inspectable by NewInspector. I agree. Maybe frederic can help. Cheers Mariano

Nov. 30, 2010

Re: [Pharo-project] [ANN] Hudson build server for Pharo

by StÃ©phane Ducasse

> > > > > > One question, you have the pharo-project.org domain, why isn't this > > hudson a subdomain of that domain. Hosted on inria, but accessible by > > the official project domain? > > > One step at a time :-) > > > > Anyway, very good news. I suppose that the download page of pharo will > > point to the latest successful build link of the hudson server very > > soon. > > > Yes... that's the goal. The artefact that people download should be generated completely > automatically. (This way we can move much faster). > > > The Dev images can be automatically generated but shouldn't be consider stable, and should NOT be the dev image that a final user download. > To build a dev image, you have to options: > > 1) Just load all the latest versions of all external packages with a large gofer script. This way is easiest to just try to build an image and see how it works. But this doesn't scale, this is not reproducible in the future, and what is worst, it can be not stable (not always the latest versions are the required). > This was the previous way to create a Pharo dev. > > 2) Using Metacello configurations. With this we can make it reproducable and stable. BUUUUT in order to make it stable, we need to define stable metacello versions for all the configuration. And this is not done automatically. we should do 1) for now but 2) as soon as we have metacello repositories. and projects without metacello descriptions will not be published in pharo-dev. Stef > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Nov. 30, 2010

Re: [Pharo-project] [ANN] Hudson build server for Pharo

by Mariano Martinez Peck

On Tue, Nov 30, 2010 at 9:37 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Nov 29, 2010, at 11:08 PM, Miguel CobÃ¡ wrote: > > > > > One question, you have the pharo-project.org domain, why isn't this > > hudson a subdomain of that domain. Hosted on inria, but accessible by > > the official project domain? > > > One step at a time :-) > > > > Anyway, very good news. I suppose that the download page of pharo will > > point to the latest successful build link of the hudson server very > > soon. > > > Yes... that's the goal. The artefact that people download should be > generated completely > automatically. (This way we can move much faster). > > The Dev images can be automatically generated but shouldn't be consider stable, and should NOT be the dev image that a final user download. To build a dev image, you have to options: 1) Just load all the latest versions of all external packages with a large gofer script. This way is easiest to just try to build an image and see how it works. But this doesn't scale, this is not reproducible in the future, and what is worst, it can be not stable (not always the latest versions are the required). This was the previous way to create a Pharo dev. 2) Using Metacello configurations. With this we can make it reproducable and stable. BUUUUT in order to make it stable, we need to define stable metacello versions for all the configuration. And this is not done automatically. So...what I want to say is that for a hudson, it doesn't make sense if the configurations are not updated. Or maybe yes it makes sense doing 1) but I don't know.... Cheers Mariano > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Nov. 30, 2010

Re: [Pharo-project] [ANN] Hudson build server for Pharo

by Marcus Denker

On Nov 29, 2010, at 11:08 PM, Miguel CobÃ¡ wrote: > > One question, you have the pharo-project.org domain, why isn't this > hudson a subdomain of that domain. Hosted on inria, but accessible by > the official project domain? > One step at a time :-) > Anyway, very good news. I suppose that the download page of pharo will > point to the latest successful build link of the hudson server very > soon. Yes... that's the goal. The artefact that people download should be generated completely automatically. (This way we can move much faster). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Nov. 30, 2010

Re: [Pharo-project] Issue 3247 in pharo: Remodel Text Constants

by pharo＠googlecode.com

Updates: Status: Closed Comment #20 on issue 3247 by marcus.denker: Remodel Text Constants http://code.google.com/p/pharo/issues/detail?id=3247 was added

Nov. 30, 2010

[Pharo-project] Issue 3359 in pharo: categorize some methods

by pharo＠googlecode.com

Status: Fixed Owner: marcus.denker Labels: Milestone-1.2 New issue 3359 by marcus.denker: categorize some methods http://code.google.com/p/pharo/issues/detail?id=3359 ... to make some more tests green Attachments: categorize methods.1.cs 5.6 KB

Nov. 30, 2010

Re: [Pharo-project] Changesets with LF/CRLF instead of CR?

by StÃ©phane Ducasse

ok stefan as a general principle, I'm open to change for the better :) Now how much? - cost to do - cost of impact - who is helping to fix bugs after - is community happy? For lot of changes we (me myself and I and a couple of others) take the cost and assume the risks. Now you see my question arriving? Are you in charge, committed (SCRUM reference to the pig and chicken story) ? Stef > Hi Eliot: > > On 29 Nov 2010, at 23:31, Eliot Miranda wrote: > >> Is there an easy way to have change sets filed out with LF instead of the horribly incompatible CR? >> >> Are conversion scipts of help? I depend on the following: > Turns out, an error that lead me to believe there are problems with LF changesets had another cause. (a missing line end at the end of the file) > > So, now I guess, the only thing to do to avoiding the CR line endings in change sets is to convince you guys that CR is not the standard line ending on OS X, and completely outdated in general. > > I would like to suggest to change the behavior of the line-end guessing in MultiByteFileStream to that end. > > Thanks > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

Nov. 30, 2010

Re: [Pharo-project] Block semantics ....

by StÃ©phane Ducasse

James I do not have the time but I have some slides on showing the difference between statically scoped lisp function and dynamically one. This illustrates the funargs problem but probably you get access to that on wikipedia. with block the object you refers from within a block may live longer than the method defining the block so you have to pay attention. Stef On Nov 29, 2010, at 9:43 PM, James Ladd wrote: > Hi Eliot, > > I was suspecting you might respond, you really know your stuff. > > I think I'm more confused now that before but in a good way. > I have more information thank to you. > > My need to fully understand blocks is to implement them in Redline. > > Maybe it will be sufficient to 'limit' the use of a block with a > return to the method in which is was defined? > ie: Method A can define the block and send it as an argument, but once > method A has been exited, the block is no longer valid, at least not > the return part. > > Does this appear most 'like' how blocks are handled in Pharo? > > Rgs, James. > >

Nov. 30, 2010

Re: [Pharo-project] TextConverter handling of binary streams

by Philippe Marschall

On 11/29/2010 03:23 PM, Sven Van Caekenberghe wrote: > Hi, > > TextConverter and its subclasses seem to break the contract of #nextFromStream: and #nextPut:toStream: when the stream #isBinary. Consider the following two examples: > > ByteArray streamContents: [ :stream | | encoder | > encoder := UTF8TextConverter new. > 'Ã©lÃ¨ve en franÃ§ais' do: [ :each | encoder nextPut: each toStream: stream ] ]. > > #[233 108 232 118 101 32 101 110 32 102 114 97 110 231 97 105 115] > > (String streamContents: [ :stream | | encoder | > encoder := UTF8TextConverter new. > 'Ã©lÃ¨ve en franÃ§ais' do: [ :each | encoder nextPut: each toStream: stream ] ]) asByteArray. > > #[195 169 108 195 168 118 101 32 101 110 32 102 114 97 110 195 167 97 105 115] > > The first answer is incorrect, the second is correct (as far as I understand it). I would agree. > This is apparently on purpose, from the implementation of, for example, UTF8TextConverter>>#nextPut:toStream: > > nextPut: aCharacter toStream: aStream > | leadingChar nBytes mask shift ucs2code | > aStream isBinary ifTrue: [^aCharacter storeBinaryOn: aStream]. > leadingChar := aCharacter leadingChar. > (leadingChar = 0 and: [aCharacter asciiValue < 128]) ifTrue: [ > aStream basicNextPut: aCharacter. > ^ aStream. > ]. > > "leadingChar > 3 ifTrue: [^ aStream]." > > ucs2code := aCharacter asUnicode. > ucs2code ifNil: [^ aStream]. > > nBytes := ucs2code highBit + 3 // 5. > mask := #(128 192 224 240 248 252 254 255) at: nBytes. > shift := nBytes - 1 * -6. > aStream basicNextPut: (Character value: (ucs2code bitShift: shift) + mask). > 2 to: nBytes do: [:i | > shift := shift + 6. > aStream basicNextPut: (Character value: ((ucs2code bitShift: shift) bitAnd: 63) + 128). > ]. > > ^ aStream. > > I would say that the contract of #nextPut:toStream: is to take a Character object and write a binary representation using a specific encoding to a stream. However, when given a #isBinary stream, it does no longer do any encoding at all ! There are many cases where Squeak/Pharo do silent coercion, where obviously something went wrong (you pass a ByteArray where a String is expected or vice versa) and the system tries to be clever about it and do something else than raising an exception and forcing you to fix your code. The result is often wrong because the system can not guess what you wanted to do. > The same is true for the other converters as well as for #nextFromStream:. > > Does anyone know why that is the case ? > > And if it is by design, how should one do UTF8 encoding on a binary stream ?? > > Thx, > > Sven > > PS: If others also think this is strange, I could make an issue, I am just not sure this is a bug. I find that strange as well. Cheers Philippe

Nov. 30, 2010

Re: [Pharo-project] Issue 3172 in pharo: NewInspector really really slow while parsing XMLNode

by pharo＠googlecode.com

Updates: Cc: jaa...(a)zoho.com Comment #2 on issue 3172 by laurent.laffont: NewInspector really really slow while parsing XMLNode http://code.google.com/p/pharo/issues/detail?id=3172 From jaayer: Hi Laurent. First, thank you for your screencasts. I am writing to you concerning this issue: http://code.google.com/p/pharo/issues/detail?id=3172&q=xml&colspec=ID%20Typ… I only discovered the above last night, as I am not a Pharo core developer and only check the issue tracker occasionally. I am a maintainer of XML-Support, however, so feel free to mail me directly with any issues you have in the future, or at the very least, please post them to the Pharo-Project, Squeak-dev or Moose-dev lists. Now, in your video, which was made back in August, you used version .74 of XML-Parser. If you look at the changelogs of XML-Parser, it is clear that much has changed since that time. It would not be unreasonable to assume that one or more of those changes is responsible for the difficulties you experienced inspecting that XML document. However, if you load version .74, the same version used in your screencast, into a Pharo 1.1 image, the problem is still there (and is in fact much worse), meaning that whatever has changed since August to bring this about, I can say with some confidence that it is not in XML-Parser. Using the latest version of XML-Parser and ignoring the question of causality for a moment, the bottleneck we're observing is in XMLNode>>printOn:. The proof is that disabling XMLNode>>printOn: makes our problem go away. Why then is XML generation suddenly such a bottleneck? The main reason appears to be that the document being inspected is, when printed, roughly 40K in size, and by inspecting it you are causing it to be printed over and over again. I tracked sends of #printOn: and found that inspecting the document and navigating to the "title" element results in #printOn: being sent 300-400 times. The recipients were the document object and the root "feed" element ~350 times. By the time you've navigated to the "feed" element and clicked the "Elements" entry to display its children, #printOn: has already been sent ~150 times. That means the remaining 150-250 sends come when you click on the "title" element or some other child element of the root, and that single additional click results in the generation of roughly 6-10 MBs of XML (150 * 40K to 250 * 40K). *That* is why it's so slow. Now, why does NewInspector cause #printOn: to be sent so much? I honestly don't know. I will forward this to the maintainers of NewInspector to get their input. Maybe NewInspector can be changed to not print inspected objects so often, or to provide them with some way to suppress its printing behavior. It must be pointed out that Pharo also comes with an object explorer that is designed specifically for this usecase of browsing deep object hierarchies. I tried exploring the document with cmd-I (capital i) and encountered no trouble.

Nov. 30, 2010