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

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

Re: [Pharo-project] A tip of the day: how to see all uses of variable

by Lukas Renggli

It works in OB. Lukas On 5 August 2011 20:13, Igor Stasenko <siguctua(a)gmail.com> wrote: > just select it in source code and press Cmd-Shift-N (Alt-Shift-N). > > In Pharo browser/inspector/debugger it works not just for global > variables (like classes), but also for: > Â - Class variables > Â - Pool variables > Â - instance variables > > Â - but not for class instance variables (we should fix that!) ;) > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 5, 2011

[Pharo-project] A tip of the day: how to see all uses of variable

by Igor Stasenko

just select it in source code and press Cmd-Shift-N (Alt-Shift-N). In Pharo browser/inspector/debugger it works not just for global variables (like classes), but also for: - Class variables - Pool variables - instance variables - but not for class instance variables (we should fix that!) ;) -- Best regards, Igor Stasenko AKA sig.

Aug. 5, 2011

Re: [Pharo-project] [Esug-list] Preparing my presentation of NativeBoost

by Igor Stasenko

On 5 August 2011 18:55, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 05.08.2011 18:02, Fernando Olivero wrote: >> >> Igor, i would like to know also the "why" i should use NB instead of >> other choices. > > There are none? ;) > If you mean "Why should I use an FFI built on top of NB over FFI/Alien?" > that's an entirely different matter. > NativeBoost (a smalltalk assembly DSL -> machinecode generator/executor) > itself does not have any equivalents (that I am aware of at least), but the > things you can build on top of it do. > Yes, it is not yet-another FFI. It opens a lot more doors, and FFI is one of the closest ones, which already open :) -- Best regards, Igor Stasenko AKA sig.

Aug. 5, 2011

Re: [Pharo-project] [Esug-list] Preparing my presentation of NativeBoost

by Henrik Sperre Johansen

On 05.08.2011 18:02, Fernando Olivero wrote: > Igor, i would like to know also the "why" i should use NB instead of > other choices. There are none? ;) If you mean "Why should I use an FFI built on top of NB over FFI/Alien?" that's an entirely different matter. NativeBoost (a smalltalk assembly DSL -> machinecode generator/executor) itself does not have any equivalents (that I am aware of at least), but the things you can build on top of it do. Cheers, Henry

Aug. 5, 2011

Re: [Pharo-project] [Esug-list] Preparing my presentation of NativeBoost

by Fernando Olivero

Igor, i would like to know also the "why" i should use NB instead of other choices. Pros and cons. Looking forward to see your talk! Fernando On Fri, Aug 5, 2011 at 1:24 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Aug 5, 2011, at 1:04 11PM, Mariano Martinez Peck wrote: > > > On Fri, Aug 5, 2011 at 1:00 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Hi, >> >> i'd like to know what you would like to know about things you don't >> know about NativeBoost :) >> because i don't know what would you like to know more: >> >> Â - more in-depth about an implementation details >> Â - more about examples and how to use it > > I much prefer this topic. Implementation details may be too low level and > maybe few can follow you. > > From a newbie point of view, I would be nice to make clear the relation > between a JIT and NativeBoost. What they do, which are the differences, etc. > For example, may NativeBoost help the JIT ? how? > Then, I would like to hear how NativeBoost is related to FFI. > > +1. > I don't think you need more implementation details than a brief overview of > how it works (store machine generated from smalltalk assembly code in > methods with a special tag, execute that instead of method body if it's been > generated). > Then spend the rest of the time on how you use that, starting at the bottom > and buildingÂ someÂ NB-versions of normal smalltalk methods directly, then how > you've implement an FFI on top of it, and how it could fit into a JIT/other > interesting stuff written entirely image-side. > IE. focus on "how do/can I use it?" rather than "how does it work?" > Cheers, > Henry >

Aug. 5, 2011

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

by Hilaire Fernandes

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. 5, 2011

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

by Hilaire Fernandes

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... 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. 5, 2011