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

Re: [Pharo-project] XML Parser, Monticello and unicode?

by Norbert Hartl

On 06.08.2010, at 14:52, Henrik Johansen wrote: > On Aug 5, 2010, at 5:37 34PM, Norbert Hartl wrote: > >> I'm trying to port the newest XML Parser from squeaksource to gemstone. In XML-Parser-AlexandreBergel.73 there is a unicode test introduced with a longer unicode xml snippet. From this release on I cannot load or merge anything. >> >> Besides that the xml snippet looks very strange it loads in pharo but not in gemstone. Unpacking the mcz on the console and examine the content showed that the encoding is indeed weird. I don't know what it is but it is neither ascii nor utf-8. Pharo loaded the snippet into a WideString instance. >> >> How does monticello handle WideString instances when written to a file? > > Rather randomly. ;) > > If you merely need to export a package so you can import in gemstone, you could change: > > MCMczWriter >> addString: internalString at: path > | member utfConverter utfStringStream| > utfConverter := TextConverter newForEncoding: 'utf8'. "(Or whatever other format Gemstone thinks .mcz definitions will be)" > utfStringStream := RWBinaryOrTextStream on: String new. > utfStringStream binary. > utfConverter class writeBOMOn: utfStringStream. > utfStringStream ascii. > utfConverter nextPutAll: internalString toStream: utfStringStream. > member := zip addString: utfStringStream contents asString as: path. > member desiredCompressionMethod: ZipArchive compressionDeflated > > (Alternatively use String new writeStream if you don't need/want to write BOM). > > Doing changes like this in the base image is unlikely without further investigation, as it would probably break reading new packages (saved in proper utf8) containing WideStrings into old images. > I haven't read the import code, but if the binary format is preferred by old images if available, it might be a reasonable compromise saving the source in utf8, provided you also include the binary file. > > Cheers, > Henry > > PS. Another fun fact I encountered when porting Assets: > Monticello uses MethodReference>>source, which kindly converts all LF / CRLFs in your source / strings in the source to CR. > So you can forget f.ex. trying to save arbitrary ByteArrays as strings in your code, and expect them to work the same when converting back to ByteArray after saving to monticello :) > Has this been reported before? If not why? This is really important. I don't think we can wait until Monticello is replaced by something different that will fix this :) There are a few things here that work together in 98% of all cases. I didn't get it fully what is going on but ZipArchiveMember>>contentStream does ... s := MultiByteBinaryOrTextStream on: (String new: self uncompressedSize). s converter: Latin1TextConverter new. ... and MultiByteBinaryOrTextStream>>defaultConverter ^ Latin1TextConverter new. These two are being used when a monticello package is being read. So we have an assumption about an encoding here. On the other hand something in the system does something similar. I don't know InputEvents and how to debug them but if I create a method EncTest>>encTest ^ 'Ã¶' I can see that ((EncTest>>#encTest literalAt: 1) at: 1) asciiValue is 246 which is something that matches latin1 to some extent. This way there is a conversion (I think at the time I press on my keyboard) to latin1. While writing a monticello package I didn't find any conversion so this might be the reason that the files become latin1 on disk and can be read back using an explicit conversion from latin1. But this does not explain how it does work with WideString. I would need to dig deeper but maybe someone of you have an idea. To estimate the possibility to change this I think we should fix this. I scanned all of my cached monticello packages. Most of them are 7bit clean. No problem for them if we change encoding. Besides XML Parser I didn't find any that contain WideString so no problem here. Some of them are latin1 encoded (like Seaside 2.8 or Seaside-InternetExplorer from 3.0). That is the biggest problem because there is no fallback and monticello does not have a version number on file format, right? I think it is still feasible to change this in monticello as the fix for users of older images will be probably only a few lines that you can apply to any version of monticello if I'm not wrong. But the change is not that easy. Norbert

Aug. 7, 2010

[Pharo-project] TextMorph without being able to be edited?

by Carla F. Griggio

Hi again, everyone! I think this might be really really silly, but I couldn't find a way to show a TextMorph without the ability to edit it's text. If I use a StringMorph to show a paragraph, it looks horrible, but if I use a TextMorph and click on it, a blue border appears and I'm able to edit the text, I don't want that to happen. Is there another morph for showing text that *only shows text* and nothing else? Or a property of TextMorph that I'm missing? Thanks! Carla

Aug. 7, 2010

[Pharo-project] Question: How can I add a items to System Browser Window menu?

by Carla F. Griggio

Hello! I want to add an item to the menu that appears when you right click on a category in the System Browser window. I think that menu is built here: Morph>>buildMetaMenu: evt But I don't want to touch that method, not SystemWindow>>buildMetaMenu: evt either, because that option would have to be visible only if my project has been loaded. Is there a way to do that? Thanks! Carla

Aug. 7, 2010

Re: [Pharo-project] Is SystemChangeNotifier notifying about protocol changed (with what changed)?

by GermÃ¡n Leiva

(arghhhhhhh too) * * *I think* that I'm having the same problem, but with: *SystemChangeNotifier uniqueInstance classAdded: newClass inCategory: newCategory* the environment of newClass has an organization that isn't SystemOrganization (is another instance of SystemOrganizer). The problem is that the newClass doesn't get set up in the instance variable category the newCategory. Any help? 2010/7/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > I'm trying to work on the integration of the new Rapckage implementation > and for this I'm trying to > shield myself from event and building system anouncements.... > > Now when a protocol is added in a class, I get a reorganized event but I do > not get the changed element.... > And I checked and I see that: > > notifyOfChangedCategoriesFrom: oldCollectionOrNil to: newCollectionOrNil > (self hasSubject and: [oldCollectionOrNil ~= newCollectionOrNil]) > ifTrue: [SystemChangeNotifier uniqueInstance > classReorganized: self subject]. > > Am I correct to think that systemNotification does not raised what changed > :( arghhhhhhh > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- GermÃ¡n Leiva LeivaGerman(a)gmail.com

Aug. 7, 2010

Re: [Pharo-project] about ToolBuilder

by StÃ©phane Ducasse

> So... let's suppose we get rid off ToolBuilder... any idea of what we should use? hand made? OB? Glamour? What I suggest is that we wait a bit. I would like to see with benjamin if we can help UIBuilder to get some windowspec and UIbuilder (VW like approach) or if this is possible to extend toolbuilder to support all the widgets. Stef > > Cheers, > Esteban > > On 2010-08-02 17:05:58 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: > >>> I agree that it should be removed, but this means that many tools need >>> to be rewritten in plain morphic. >> do you know which ones? >> Because a lot of buildwith: methods are not used in fact. >>> Lukas >>> 2010/8/2 Richard Durr <richard.durr(a)googlemail.com>: >>>> +1. >>>> See Gilad's text about least common denominator in UI-widgetery >>>> On Fri, Jul 30, 2010 at 12:20 PM, stephane ducasse >>>> <stephane.ducasse(a)free.fr> wrote: >>>>> Hi guys >>>>> during the sprint I discussed with Gary about ToolBuilder and we think >>>>> that it would be better to remove it >>>>> since a lot of new widgets are not covered so this means that we will be >>>>> constantly limiting ourselves. >>>>> Of course ToolBuilder is a nice idea (if we would have several UI >>>>> framework). So far we got only one >>>>> and we would have several we would have to take the smallest common >>>>> denominator. >>>>> Another idea would be to extend toolBuilder to support new widgets. >>>>> So what do you think? >>>>> Stef >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 7, 2010

Re: [Pharo-project] Trying to combine two images

by Schwab,Wilhelm K

Andreas, The effect from your examples was very subtle on my display, but it looked promising so I started hacking it into my code. The results were initially very strange, but I had been badly mangling the bitblt on my end. Things went from weird to simply ugly and I started comparing the types of forms. I was using ColorForm, so I switched that to Form (interestingly I had only recently started using ColorForm) and the results are now really nice. I am curious what you meant about simplifying things if my mask were alpha. AFAIK, I am perfectly willing to use it. What would stop me? Thanks!! Bill

Aug. 7, 2010

[Pharo-project] Trying to combine two images

by Schwab,Wilhelm K

Are there any good examples of using a mask to highlight portions of an image? I have an onion-skin effect in mind, but could live with almost anything that is easy to see and does not obliterate the underlying image. The goal is to paint a mask that will select irregular regions of an image. If I have a black and white mask, I can use #eraseShape: and #reverse to get two separate images, and I appear to be able to make the masked portion of one of them transpaent and can (not terribly well) highlight the masked portion of the other. Things quickly sprial down hill when I try to combine the two pieces. Any pointers would be appreciatiated. Bill

Aug. 7, 2010

Re: [Pharo-project] about ToolBuilder

by Esteban Lorenzano

So... let's suppose we get rid off ToolBuilder... any idea of what we should use? hand made? OB? Glamour? Cheers, Esteban On 2010-08-02 17:05:58 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: >> I agree that it should be removed, but this means that many tools need >> to be rewritten in plain morphic. > > do you know which ones? > Because a lot of buildwith: methods are not used in fact. > >> Lukas >> >> 2010/8/2 Richard Durr <richard.durr(a)googlemail.com>: >>> +1. >>> See Gilad's text about least common denominator in UI-widgetery >>> >>> On Fri, Jul 30, 2010 at 12:20 PM, stephane ducasse >>> <stephane.ducasse(a)free.fr> wrote: >>>> >>>> Hi guys >>>> >>>> during the sprint I discussed with Gary about ToolBuilder and we think >>>> that it would be better to remove it >>>> since a lot of new widgets are not covered so this means that we will be >>>> constantly limiting ourselves. >>>> Of course ToolBuilder is a nice idea (if we would have several UI >>>> framework). So far we got only one >>>> and we would have several we would have to take the smallest common >>>> denominator. >>>> Another idea would be to extend toolBuilder to support new widgets. >>>> So what do you think? >>>> >>>> Stef >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 6, 2010

Re: [Pharo-project] XML Parser, Monticello and unicode?

by StÃ©phane Ducasse

Henrik can you open bug entry for your nice gems? we should document and make sure that we will fix that. Stef On Aug 6, 2010, at 2:52 PM, Henrik Johansen wrote: > On Aug 5, 2010, at 5:37 34PM, Norbert Hartl wrote: > >> I'm trying to port the newest XML Parser from squeaksource to gemstone. In XML-Parser-AlexandreBergel.73 there is a unicode test introduced with a longer unicode xml snippet. From this release on I cannot load or merge anything. >> >> Besides that the xml snippet looks very strange it loads in pharo but not in gemstone. Unpacking the mcz on the console and examine the content showed that the encoding is indeed weird. I don't know what it is but it is neither ascii nor utf-8. Pharo loaded the snippet into a WideString instance. >> >> How does monticello handle WideString instances when written to a file? > > Rather randomly. ;) > > If you merely need to export a package so you can import in gemstone, you could change: > > MCMczWriter >> addString: internalString at: path > | member utfConverter utfStringStream| > utfConverter := TextConverter newForEncoding: 'utf8'. "(Or whatever other format Gemstone thinks .mcz definitions will be)" > utfStringStream := RWBinaryOrTextStream on: String new. > utfStringStream binary. > utfConverter class writeBOMOn: utfStringStream. > utfStringStream ascii. > utfConverter nextPutAll: internalString toStream: utfStringStream. > member := zip addString: utfStringStream contents asString as: path. > member desiredCompressionMethod: ZipArchive compressionDeflated > > (Alternatively use String new writeStream if you don't need/want to write BOM). > > Doing changes like this in the base image is unlikely without further investigation, as it would probably break reading new packages (saved in proper utf8) containing WideStrings into old images. > I haven't read the import code, but if the binary format is preferred by old images if available, it might be a reasonable compromise saving the source in utf8, provided you also include the binary file. > > Cheers, > Henry > > PS. Another fun fact I encountered when porting Assets: > Monticello uses MethodReference>>source, which kindly converts all LF / CRLFs in your source / strings in the source to CR. > So you can forget f.ex. trying to save arbitrary ByteArrays as strings in your code, and expect them to work the same when converting back to ByteArray after saving to monticello :) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 6, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Norbert Hartl

On 06.08.2010, at 23:16, StÃ©phane Ducasse wrote: >> >> Removing the packages from the MetacelloRepository as Stephane suggested would just make them platform dependent. > > I missed your point. I did not say to remve the package form metacello but to copy them so that we do not depend on a server > that suddenly disappear from earth. > Ah, ok, I got it somewhat different. > Now let us give a try and learn. > Yep, time will tell anyway. Norbert

Aug. 6, 2010