- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Poll: missing libraries to support business

by Igor Stasenko

- a vector-based graphics engine, which can use GPU for fast rendering. :) -- Best regards, Igor Stasenko AKA sig.

Aug. 7, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by StÃ©phane Ducasse

On Aug 7, 2010, at 2:00 PM, Philippe Marschall wrote: > On 02.08.2010 21:50, StÃ©phane Ducasse wrote: >> Hi guys >> >> with the experience around the XMLRPC project, ESUG wants to change strategy to help growing business at the technical >> level. So what are the key areas where you think that effort should be supported to help you making business in smalltalk? > > Rather than imagining what problems non-users could have I'd focus on > what problems existing users have. Instead of building libraries that > you'll have to maintain forever I'd focus in infrastructure that allows > users to write the libraries they need themselves. Yes! But a poll is interesting. > Executive summary: > - HTTP(S) > - SqueakDBX > - VM/Cog/kernel/FFI/Alien The last line is really into our radar and our engineer will make sure FFI/Alien will work 100% Noury and luc really need sockets and started to rewrite them using Alien and this something that we want to push too. > Something that always comes up is a usable HTTP client that does HTTPS, > proxies, authentication, multipart, not have to load the entire > response/request into memory, probably even keep-alive. WebClient could > be the solution here once you have documentation, examples and don't > need an override on String >> #,. As more and more things are HTTP based > these days having a good HTTP story is important. Again WebClient has an > advantage here because it answers both the client and the server part. > NTLMv2 would be awesome but may not be possible. For WebClient this is good that andreas started to clean that part we really want to support that effort and this was also in our radar > What also seems to come up frequently is relational databases. I have > already meat people who told me "I would use Squeak/Pharo over dialect X > if only I could connect to Oracle". Having a common interface for > relational databases despite all the "NoSQL" hype is important even if > it requires installing native (C) client libraries. SqueakDBX seems to > be the only option here right now. this is why ESUG supported this project over the years. > And finally having a fast and stable kernel and runtime including > Sockets/Semaphores/weak array finalization. That includes helping Eliot > to make Cog a replacement for the current VM. That includes having a > prebuilt Coq VM available with warning signs. That includes having an > easy way to bind C libraries without writing a plugin. See above. Yes > That includes > non-blocking FFI calls. That may include having a way to do > sendfile()/TransmitFile() on sockets. That may include instead of having > Semaphore, Mutex and Monitor only having the class that you're supposed > to use. That may include a ReadWriteLock. I do not know :) but we will know it soon (by january or february) > > Cheers > Philippe > > > _______________________________________________ > 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] HTTP client library in Pharo?

by Philippe Marschall

On 04.08.2010 19:15, Andreas Raab wrote: > On 8/4/2010 9:57 AM, Mariano Martinez Peck wrote: >> Hi Adrei, excellent :) >> >> BTW, for HTTP Client you should cc Andreas Raab or squeak mailing >> list.... > > Squeak-dev please > (http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev) > >> On Wed, Aug 4, 2010 at 6:08 PM, Andrei Stebakov <lispercat(a)gmail.com >> <mailto:lispercat@gmail.com>> wrote: >> >> I also found that cookies were not correctly sent. >> Every cookie was sent with its own "Cookie: " header which is not >> correct. > > I'm curious, why do you think that's incorrect? My understanding is that > RFC 2616 explicitly allows that: > > "Multiple message-header fields with the same field-name MAY be > present in a message if and only if the entire field-value for that > header field is defined as a comma-separated list [i.e., #(values)]. It > MUST be possible to combine the multiple header fields into one > 'field-name: field-value' pair, without changing the semantics of the > message, by appending each subsequent field-value to the first, each > separated by a comma." You're correct, but that doesn't mean the implementations follow the spec :-(. I can only speak for Set-Cookie, there you have to send each cookie on a new line because the expires date format includes a comma and Firefox and IE can't handle that. Cheers Philippe

Aug. 7, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by Philippe Marschall

On 02.08.2010 21:50, StÃ©phane Ducasse wrote: > Hi guys > > with the experience around the XMLRPC project, ESUG wants to change strategy to help growing business at the technical > level. So what are the key areas where you think that effort should be supported to help you making business in smalltalk? Rather than imagining what problems non-users could have I'd focus on what problems existing users have. Instead of building libraries that you'll have to maintain forever I'd focus in infrastructure that allows users to write the libraries they need themselves. Executive summary: - HTTP(S) - SqueakDBX - VM/Cog/kernel/FFI/Alien Something that always comes up is a usable HTTP client that does HTTPS, proxies, authentication, multipart, not have to load the entire response/request into memory, probably even keep-alive. WebClient could be the solution here once you have documentation, examples and don't need an override on String >> #,. As more and more things are HTTP based these days having a good HTTP story is important. Again WebClient has an advantage here because it answers both the client and the server part. NTLMv2 would be awesome but may not be possible. What also seems to come up frequently is relational databases. I have already meat people who told me "I would use Squeak/Pharo over dialect X if only I could connect to Oracle". Having a common interface for relational databases despite all the "NoSQL" hype is important even if it requires installing native (C) client libraries. SqueakDBX seems to be the only option here right now. And finally having a fast and stable kernel and runtime including Sockets/Semaphores/weak array finalization. That includes helping Eliot to make Cog a replacement for the current VM. That includes having a prebuilt Coq VM available with warning signs. That includes having an easy way to bind C libraries without writing a plugin. That includes non-blocking FFI calls. That may include having a way to do sendfile()/TransmitFile() on sockets. That may include instead of having Semaphore, Mutex and Monitor only having the class that you're supposed to use. That may include a ReadWriteLock. Cheers Philippe

Aug. 7, 2010

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

by StÃ©phane Ducasse

>>> >>> > 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 :) the anwser is: - check bug entries - add new one if necessary - propose a fix if possible - else wait. > > 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. how do you do that? > 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. This is not clear to me what is the problem and potential solution. I was not concentrated enough on pharo :( > > Norbert > > _______________________________________________ > 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] Question: How can I add a items to System Browser Window menu?

by StÃ©phane Ducasse

On Aug 7, 2010, at 12:22 PM, Carla F. Griggio wrote: > 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. exactly nobody should change the core methods just declare intention. > > Is there a way to do that? sure. you should use a pragma <menu> here is for example how this is done for ScriptLoader menuCommandOn: aBuilder <worldMenu> (aBuilder item: #'Integrator Menu') order: 1.5; precondition: [self currentlyIntegratingChanges]; parent: #System; action: [ScriptLoader releaseMenu] > > Thanks! > Carla > _______________________________________________ > 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] 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