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

[Pharo-project] Polymorph composites

by Schwab,Wilhelm K

Hello, With no small push from Andreas (and Pharo in general), I have been able to build something that is pretty much exactly what I envisioned. That attached has some identifiers blocked out but hopefully conveys what I am trying to do. The draw/erase and square/circle buttons do what you would expect, and apply to a monochrome mask that is represented by the dotted pattern. The next step is to integrate this into a larger shell, and this is where either I have something to learn of Polymorph has room to grow. What you see should be (in Dolphin parlance) a CompositePresenter that can readily be embedded in other morphs/presenters/whatever-we-call-them. As it is, I get a jumbled mess unless I create this in a system or standard window :( The images naturally come in three interlaced sequences of pairs. It would be very natural to show multiple instances of this composite structure. Is there a way to re-use it w/o a shell? Bill

Aug. 7, 2010

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

by Schwab,Wilhelm K

Stef, Great news about the sockets rewrite!! On my wish list includes OpenSSL (Andreas appears to be making strides there??) and to see the end of polling for connections. Ideally, one could set the type of socket to be either TCP, UDP (for those who must), IrDA, etc. and have it work. It would also be nice to be able to get events when the other side closes the connection. Good network programming requires good error handling, and asynchronous activity. One must be able to reboot peers, turn off hubs, yank wires (name it) and not have the software hang. I don't think I care whether that is done with asynch sockets or blocking ones called on OS threads, but we're not done until it "never" hangs. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, August 07, 2010 10:50 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Poll: missing libraries to support business 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 _______________________________________________ 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 Andrei Stebakov

Yes, that's correct for Set-cookie (the response), each has its own line. "Cookies: " for request should be all in one line. On Sat, Aug 7, 2010 at 8:05 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > 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 > > > _______________________________________________ > 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 07.08.2010, at 13:19, StÃ©phane Ducasse wrote: >>>> >>>> >> 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. > I replied to Henriks mail. It was meant as a question to him because he knows about the topic. I see I need to be more clear next time. And btw. this was _not_ an answer to my question. >> >> 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? for i in `find . -name "*.mcz"`; do echo $i; unzip -qc $i snapshot/source.st | enca -L none; done > >> 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 :( It is not clear to me, either. That's why I am asking. I'm willing to track this down any further. At least i want to open a substantial ticket. But a little bit more information would be helpful. Norbert

Aug. 7, 2010

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