- Pharo-dev - lists.pharo.org

Re: [Pharo-project] UTF-8 support when exporting to XML

by StÃ©phane Ducasse

Hilaire could you write some comments in the XMLParser/Writer classes and methods so that next time we do not get into the same problem? Stef On Aug 5, 2011, at 5:23 PM, Hilaire Fernandes wrote: > So far it was an orthogonal problem to XML Parser. > > I have to submit to XMLWriter a stream with UTF8 converter. > > StandardFileStream does not handle it, but MultiByteFileStream does. > > Thanks Henrik. It avoids me to check with latest XMLParser. > > Hilaire > > Le 05/08/2011 13:21, Hilaire Fernandes a Ã©crit : >> Hello, >> >> I am wondering, does latest XML Parser get the string value really >> exported to UTF-8. >> I am still using an old version #20 of XMLParser (for code >> compatibility) and I noted that Pharo accented string (still in 8 bits >> forms as far as I can see) are not converted to UTF-8 when exported in >> the XML file. >> >> Is it still the case with latest XML Parser? >> >> Hilaire >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

Aug. 6, 2011

Re: [Pharo-project] String input not in UTF-8

by StÃ©phane Ducasse

On Aug 5, 2011, at 4:41 PM, Hilaire Fernandes wrote: > I gave a look at the latest XMLParser but the API is different with a > lot broken code on my face. Does XMLWriter class>>on: obsolete ? It bugs > me with that but the class and method are still there, a Monticello > trick I forget about? > I don't even now how to port to new API. Is there a port guide? > I guess this is for the better, but still frustrating and distracting > from the main task... indeed We should really invest into some main packages. For example I worked on SOUP to add comments and add new tests. Now we (the core) do not have the energy to work on the core and external packages. I hope it will change when the core gets fixed. > > > > Le 05/08/2011 16:23, Henrik Johansen a Ã©crit : >> >> On Aug 5, 2011, at 3:41 54PM, Hilaire Fernandes wrote: >> >>> Le 05/08/2011 13:28, Henrik Johansen a Ã©crit : >>>> >>>> On Aug 5, 2011, at 1:14 35PM, Hilaire Fernandes wrote: >>>> >>>>> It seems like when inputing accented character it is not by default in >>>>> UTF-8. >>>>> Is it the case with Pharo 1.3 ? >>>>> >>>>> Hilaire >>>>> >>>>> >>>>> -- >>>>> Education 0.2 -- http://blog.ofset.org/hilaire >>>> >>>> I'm not sure what you mean. >>>> When in image, all the way from InputEvents to String representation, you only deal with Unicode codePoints. >>> >>> Is seems it is 8 bits chars, when exported through XMLParser, it is >>> 8bits string. I need to investigate further. >>> >>> Hilaire >> It is an 8-bit character, since the codePoint fits in one byte. (see a) >> Accented characters like Ã© could be either: >> a) One Unicode codepoint (U+00E9 (decimal 233) small acute e ) >> b) Two Unicode codepoints ( U+0301 (decimal 769) combining acute accent + U0065 (decimal 101) small e ). >> >> Internally, you'd see strings with character values corresponding to those listed as decimal, ie the unicode codePoints. >> b) would be a WideString, as 769 does not fit in a byte. >> >> However, if correctly converted to UTF8, their representations should be; >> a) represented in 2 bytes ; 16r C3A9 >> b) represented in 3 bytes: 16r CD81 65. >> >> Ie. it seems XMLParser does not encode it properly to utf8 when exporting. >> Note: This is perfectly legal if the document contains an encoding attribute specifying a one-byte encoding like iso-8859-1 or windows-1252. >> (starts with <?xml version="1.0" encoding="windows-1252" ?> or some such) >> Absent such an attribute, or a BOM indicating another Unicode encoding though, it is a bug. >> >> Cheers, >> Henry >> >> >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

Aug. 6, 2011

Re: [Pharo-project] Zinc: urls without scheme

by StÃ©phane Ducasse

On Aug 5, 2011, at 10:52 AM, Sven Van Caekenberghe wrote: > Hi Igor, > > On 05 Aug 2011, at 10:08, Igor Stasenko wrote: > >> 'www.squeaksource.com' asZnUrl host -> nil > > That seems like a bug to me, I'll look into it. Thanks for reporting this. > >> 'http://www.squeaksource.com' asZnUrl host -> 'www.squeaksource.com' >> >> i wonder if url should have notion of default scheme and if sheme not >> specified, use a default one i.e. 'http:' ? > > Hmm, that is more or less by design, I'll think about it. > > A default can also be explicit in the message like #portOrDefault that way the object keeps representing what was parsed, but the user specifies what kind of default behavior (s)he wants. Yes it sound like a good idea. > > Regards, > > Sven > > >

Aug. 6, 2011

Re: [Pharo-project] Zinc: urls without scheme

by StÃ©phane Ducasse

Igor use gofer. It is good to minimise the number of libraries to maintain. Stef On Aug 5, 2011, at 11:07 AM, Igor Stasenko wrote: > On 5 August 2011 10:52, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> Hi Igor, >> >> On 05 Aug 2011, at 10:08, Igor Stasenko wrote: >> >>> 'www.squeaksource.com' asZnUrl host -> nil >> >> That seems like a bug to me, I'll look into it. Thanks for reporting this. >> >>> 'http://www.squeaksource.com' asZnUrl host -> 'www.squeaksource.com' >>> >>> i wonder if url should have notion of default scheme and if sheme not >>> specified, use a default one i.e. 'http:' ? >> >> Hmm, that is more or less by design, I'll think about it. >> >> A default can also be explicit in the message like #portOrDefault that way the object keeps representing what was parsed, but the user specifies what kind of default behavior (s)he wants. >> > > Well, since zinc is mostly for http/web.. i would expect that it using > appropriate defaults for urls it use. > > The problem is in: > > ScriptLoader new installingInstaller. > > without default scheme this thing is broken, since it using url > without scheme. :( > > Of course i could use gofer for loading it.. but i found this is most > easy way to load installer. > > -- > Best regards, > Igor Stasenko AKA sig. >

Aug. 6, 2011

[Pharo-project] Smalltalk job offer in Luxembourg

by StÃ©phane Ducasse

Dear friends For one of its customer, LOGOS IT Services is looking for external support by one consultant (f/m) Senior Software Developer - Smalltalk Role/Area: Developer to participate to technical design, coding, unit testing and bug fixing Qualifications/Required Skills Senior Software Engineer with advanced SmallTalk development skills. Minimum 5 years experience in smalltalk development. Experience in financial industry is required If possible, ability to coach people English is the working language Motivation and ability to ramp up rapidly is key Additional Information Starting Date : asap 3 month contracts, renewable, estimated duration of the mission: until June 2012 Location: Luxembourg Please contact LOGOS IT Services SA 427, Route de Thionville L - 5 8 8 7 A l z i n g e n TÃ©l: +352.26.36.55.33 Fax: +352.26.36.55.35 Mail: info(a)logos-its.com

Aug. 6, 2011

[Pharo-project] about coral

by StÃ©phane Ducasse

Hi frank Oscar is not in charge since a long time about coral. In fact it had always been my iea, and since oscar like scripting language he was participating. Now Damien is helping a lot. If you have changes that you think can go in our version please send them. I do not know why the REPL is not working anymore and probably that we should use the stdout that were introduced in 1.3 This has been years that I want a smalltalk with a scripting layer and if you want to join you are welcome. Stef ---------- Forwarded message ---------- From: Frank Shearar <frank.shearar(a)gmail.com> Date: Fri, Aug 5, 2011 at 6:33 PM Subject: [squeak-dev] "Pharoism" package? To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Hi, I did some work yesterday [1] getting Coral (a scripting framework for Pharo: http://www.squeaksource.com/Coral.html) working in Trunk. I made a few adjustments to Coral itself, mailing Oscar Nierstrasz the changes (what look to be getting Coral to work with the latest Filesystem code, post-large-refactor), and had to add a few methods to Squeak that Coral was expecting. Presumably these were methods renamed by Pharo: Character >> join: String >> join: Class >> addInstVarNamed: MetaClass >> addInstVarNamed: Class >> subclass: SmalltalkImage >> vmFullPath Symbol >> isBinary My question's a bit broader: there are many more Pharo developers than Squeak developers, it seems. They're doing lots of cool stuff. We can easily port these cool things to Squeak (at least, at the moment). If anyone else is doing this kind've thing, perhaps it's worthwhile either adding these kinds of methods to Grease, or having a general "Pharoisms" package. It's not all one-way, of course: having things easily loadable into Squeak means that Squeak hackers (like me) can more easily contribute to interesting packages (like Coral) without having to keep track of two communities. (Coral could, with some love, become a full REPL, which is something I really want.) frank [1] http://stackoverflow.com/questions/6938114/a-smalltalk-implementation-with-… -- Mariano http://marianopeck.wordpress.com

Aug. 6, 2011

Re: [Pharo-project] [OT] Smalltalk on JVM

by Pat Maddox

Check out redline! http://redline.st/ On Aug 4, 2011, at 1:22 PM, Torsten Bergmann wrote: > At http://medianetwork.oracle.com/media/show/16803 > scroll down and there you will find a new video > "A Renaissance VM: One Platform, Many Languages" > with a talk about the new "invokedynamic" (JSR292). > > John Rose also talks about all this in the context > of Smalltalk. So if you are interested in ST and VM's > this may be interesting too. > > There is also RTalk which maybe interesting in this > context too, see http://astares.blogspot.com/2011/08/smalltalk-on-jvm.html > > Bye > T. > > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone >

Aug. 6, 2011

Re: [Pharo-project] Questions about Ocean

by Igor Stasenko

On 6 August 2011 00:56, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 August 2011 00:15, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >> >> On 4 aoÃ»t 2011, at 17:25, Igor Stasenko wrote: >> >>> 1. why library does not serve as a factory for objects? >>> >>> I think it should, so one can write: >>> >>> library := MyLibrary new. >>> socket := library createTcpSocket. >>> >>> socket connectTo: (library ipv4Address: 'x.y.z' port: 1000) >>> >>> I think it could simplify a lot of things. >> >> We aim at having multiple libraries and the socket choosing the default one, or leting the user choosing a different one. > > But this is orthogonal to my suggestion. > From user's POV, socket should support certain protocol. Period. > Nobody interesting where it comes from, who creating it and where. > Especially, that library "owns" sockets and only library knows how to > manage them , so it is logical that library should serve as a factory > for sockets > (even if all libraries will use the same class, it is still better, > since library have chance to control all aspects of its initialization > before hanging it over to user). > Because right now, if i issue OCNSocket new it answers a uninitialized > socket in indefinitive (and therefore useless) state , and Â so you > putting an obligation of proper object initialization outside of your > framework , which is straight road to numerous gotchas and pitfalls. > > Instead , if you let user to ask library to create a socket, then he > will be confident that answered socket instance is well formed and > ready for use. > >> Still we didn't implement this protocol so far, though the bricks are there (see OCNNetworkLibraryProxyFactory) >> > :) > >>> >>> 2. what is OCNConversationTcpSocket and what its role? As to me it is >>> unnecessary. >> >>> I'd rather leave only single socket class in kernel. And for others, i >>> think it would be better to use delegation instead of subclassing. >>> So you will have: >>> MyCustomRoleSocket (socket) -> OCNSocket (socketid, library) -> library >>> >> >> TCP conversation socket is the socket that is used for exchanging data (sending / receiving). >> It's role is different from a TCP server socket which is there for establishing connections. >> > > A server socket has to provide only few things to users (after it > bound and started listening): > Â - accept new connection > Â - close > > The rest of socket protocol is useless and will produce the errors if > you use it. > So, instead of subclassing, a server socket can be a simple class, > subclassed from Object and have only two!! methods , which makes life > extremely easy for users, > because they don't have to guess how to use it, and don't have to fear > that some other components of library could send > a wrong message (defined in superclass) to this socket instance which > may lead to error. > > server := TcpServerSocket on: someOCNSocket. or even better: server := TcpServerSocket listenOn: address using: someOCNSocket. like that, OCNSocket don't have to implement #bind: and #listen: protocol, only library has to do it, and only TcpServerSocket have to send those messages. > > >> Users of Ocean are not supposed to subclass these classes. >> If you want to implement a protocol, you need to go through a decorator pattern or a similar solution. >> > Yes, and i am asking, why these two subclasses are not decorators themselves? > Because they are using only a subset of socket's functionality (you > cannot connect once you already connected, > you cannot send or receive data using socket which listening connections etc). > >> >>> 3. Why OCNSocket keeps track its "state"? I think it would be better >>> to always ask system about its state, >>> because you never know for sure.. >>> >> Yes. But, so far we don't know how to do it. Can you get the state from the socket plugin? It should be possible in unix, though not trivial. >> Don't know about Windows. >> >>> 4. error handling is below the waterline and needs to be addressed properly :) >>> See the amount of error codes which connect() could produce. Where are they? >>> Also, there is a lot of missing things for finer socket controls, like >>> select(), poll(), fnctl() >>> setsockopt() etc.. with all flags. >>> So you have a lot to do :) >>> >> Ocean is far from complete. Still have already introduced some exceptions. >> Still, we don't want to have too many to avoid making the library too complicated. >> This is why we simplified the socket's life-cycle. >> > I know. Still, there has to be proper error handling. And it won't > work without knowing exactly what happed > (if function answers -1) , you should check errono etc. > >>> 5. where i can put my code for NativeBoost backend of Ocean? >>> >> It seems that you are willing to introduce a new back-end for Ocean. >> So, you'll have to create a new library. > > I did that. But protocols are too fizzy right now, so i stop working > on it for later, when i'll have a free time to do it. > Meanwhile i will upload the library as a separate package to Ocean repository. > >> You can take as an example, the plugin-library (OCNSocketPluginLibrary) as an example since it is the most advanced. >> Still, what you want to do is closer to the currently staled posix-library, based on Alien. >> > yes yes > >> >>> 6. I understand that project is far from being complete, so don't >>> treat my comments as an arrogant asshole. Just my thoughts, >>> how it would be better to implement :) >>> >> Thanx for the feedback. >> >>> I created couple of classes and couple of tests (i could create >>> socket, connect to remote host), but i stopping now, >>> since of the above issues. >>> Ideally, i would like to introduce you to NativeBoost and to see if >>> you like it and if you can use it without my direct involvement >>> (because it's already too much on my plate anyways ;) >>> >> Cool! We do like NativeBoost. >> We can pair program a bit together next time we meet. >> At least in the Esug confo @ Edinburgh :-) >> > Yes. We can :) > >> Noury >> http://car.mines-douai.fr/noury >> -- >> -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) >> http://www.univ-valenciennes.fr/congres/jfsma2011/ >> 17-19 Octobre 2011, Valenciennes, France >> >> -5th International Conference on Smalltalk Technologies >> http://www.fast.org.ar >> November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina) >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Aug. 5, 2011

Re: [Pharo-project] Questions about Ocean

by Igor Stasenko

On 6 August 2011 00:15, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > On 4 aoÃ»t 2011, at 17:25, Igor Stasenko wrote: > >> 1. why library does not serve as a factory for objects? >> >> I think it should, so one can write: >> >> library := MyLibrary new. >> socket := library createTcpSocket. >> >> socket connectTo: (library ipv4Address: 'x.y.z' port: 1000) >> >> I think it could simplify a lot of things. > > We aim at having multiple libraries and the socket choosing the default one, or leting the user choosing a different one. But this is orthogonal to my suggestion. >From user's POV, socket should support certain protocol. Period. Nobody interesting where it comes from, who creating it and where. Especially, that library "owns" sockets and only library knows how to manage them , so it is logical that library should serve as a factory for sockets (even if all libraries will use the same class, it is still better, since library have chance to control all aspects of its initialization before hanging it over to user). Because right now, if i issue OCNSocket new it answers a uninitialized socket in indefinitive (and therefore useless) state , and so you putting an obligation of proper object initialization outside of your framework , which is straight road to numerous gotchas and pitfalls. Instead , if you let user to ask library to create a socket, then he will be confident that answered socket instance is well formed and ready for use. > Still we didn't implement this protocol so far, though the bricks are there (see OCNNetworkLibraryProxyFactory) > :) >> >> 2. what is OCNConversationTcpSocket and what its role? As to me it is >> unnecessary. > >> I'd rather leave only single socket class in kernel. And for others, i >> think it would be better to use delegation instead of subclassing. >> So you will have: >> MyCustomRoleSocket (socket) -> OCNSocket (socketid, library) -> library >> > > TCP conversation socket is the socket that is used for exchanging data (sending / receiving). > It's role is different from a TCP server socket which is there for establishing connections. > A server socket has to provide only few things to users (after it bound and started listening): - accept new connection - close The rest of socket protocol is useless and will produce the errors if you use it. So, instead of subclassing, a server socket can be a simple class, subclassed from Object and have only two!! methods , which makes life extremely easy for users, because they don't have to guess how to use it, and don't have to fear that some other components of library could send a wrong message (defined in superclass) to this socket instance which may lead to error. server := TcpServerSocket on: someOCNSocket. > Users of Ocean are not supposed to subclass these classes. > If you want to implement a protocol, you need to go through a decorator pattern or a similar solution. > Yes, and i am asking, why these two subclasses are not decorators themselves? Because they are using only a subset of socket's functionality (you cannot connect once you already connected, you cannot send or receive data using socket which listening connections etc). > >> 3. Why OCNSocket keeps track its "state"? I think it would be better >> to always ask system about its state, >> because you never know for sure.. >> > Yes. But, so far we don't know how to do it. Can you get the state from the socket plugin? It should be possible in unix, though not trivial. > Don't know about Windows. > >> 4. error handling is below the waterline and needs to be addressed properly :) >> See the amount of error codes which connect() could produce. Where are they? >> Also, there is a lot of missing things for finer socket controls, like >> select(), poll(), fnctl() >> setsockopt() etc.. with all flags. >> So you have a lot to do :) >> > Ocean is far from complete. Still have already introduced some exceptions. > Still, we don't want to have too many to avoid making the library too complicated. > This is why we simplified the socket's life-cycle. > I know. Still, there has to be proper error handling. And it won't work without knowing exactly what happed (if function answers -1) , you should check errono etc. >> 5. where i can put my code for NativeBoost backend of Ocean? >> > It seems that you are willing to introduce a new back-end for Ocean. > So, you'll have to create a new library. I did that. But protocols are too fizzy right now, so i stop working on it for later, when i'll have a free time to do it. Meanwhile i will upload the library as a separate package to Ocean repository. > You can take as an example, the plugin-library (OCNSocketPluginLibrary) as an example since it is the most advanced. > Still, what you want to do is closer to the currently staled posix-library, based on Alien. > yes yes > >> 6. I understand that project is far from being complete, so don't >> treat my comments as an arrogant asshole. Just my thoughts, >> how it would be better to implement :) >> > Thanx for the feedback. > >> I created couple of classes and couple of tests (i could create >> socket, connect to remote host), but i stopping now, >> since of the above issues. >> Ideally, i would like to introduce you to NativeBoost and to see if >> you like it and if you can use it without my direct involvement >> (because it's already too much on my plate anyways ;) >> > Cool! We do like NativeBoost. > We can pair program a bit together next time we meet. > At least in the Esug confo @ Edinburgh :-) > Yes. We can :) > Noury > http://car.mines-douai.fr/noury > -- > -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) > http://www.univ-valenciennes.fr/congres/jfsma2011/ > 17-19 Octobre 2011, Valenciennes, France > > -5th International Conference on Smalltalk Technologies > http://www.fast.org.ar > November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina) > -- Best regards, Igor Stasenko AKA sig.

Aug. 5, 2011

Re: [Pharo-project] Questions about Ocean

by Noury Bouraqadi

On 4 aoÃ»t 2011, at 17:25, Igor Stasenko wrote: > 1. why library does not serve as a factory for objects? > > I think it should, so one can write: > > library := MyLibrary new. > socket := library createTcpSocket. > > socket connectTo: (library ipv4Address: 'x.y.z' port: 1000) > > I think it could simplify a lot of things. We aim at having multiple libraries and the socket choosing the default one, or leting the user choosing a different one. Still we didn't implement this protocol so far, though the bricks are there (see OCNNetworkLibraryProxyFactory) > > 2. what is OCNConversationTcpSocket and what its role? As to me it is > unnecessary. > I'd rather leave only single socket class in kernel. And for others, i > think it would be better to use delegation instead of subclassing. > So you will have: > MyCustomRoleSocket (socket) -> OCNSocket (socketid, library) -> library > TCP conversation socket is the socket that is used for exchanging data (sending / receiving). It's role is different from a TCP server socket which is there for establishing connections. Users of Ocean are not supposed to subclass these classes. If you want to implement a protocol, you need to go through a decorator pattern or a similar solution. > 3. Why OCNSocket keeps track its "state"? I think it would be better > to always ask system about its state, > because you never know for sure.. > Yes. But, so far we don't know how to do it. Can you get the state from the socket plugin? It should be possible in unix, though not trivial. Don't know about Windows. > 4. error handling is below the waterline and needs to be addressed properly :) > See the amount of error codes which connect() could produce. Where are they? > Also, there is a lot of missing things for finer socket controls, like > select(), poll(), fnctl() > setsockopt() etc.. with all flags. > So you have a lot to do :) > Ocean is far from complete. Still have already introduced some exceptions. Still, we don't want to have too many to avoid making the library too complicated. This is why we simplified the socket's life-cycle. > 5. where i can put my code for NativeBoost backend of Ocean? > It seems that you are willing to introduce a new back-end for Ocean. So, you'll have to create a new library. You can take as an example, the plugin-library (OCNSocketPluginLibrary) as an example since it is the most advanced. Still, what you want to do is closer to the currently staled posix-library, based on Alien. > 6. I understand that project is far from being complete, so don't > treat my comments as an arrogant asshole. Just my thoughts, > how it would be better to implement :) > Thanx for the feedback. > I created couple of classes and couple of tests (i could create > socket, connect to remote host), but i stopping now, > since of the above issues. > Ideally, i would like to introduce you to NativeBoost and to see if > you like it and if you can use it without my direct involvement > (because it's already too much on my plate anyways ;) > Cool! We do like NativeBoost. We can pair program a bit together next time we meet. At least in the Esug confo @ Edinburgh :-) Noury http://car.mines-douai.fr/noury -- -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)

Aug. 5, 2011