January 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20464

by Marcus Denker

Jan. 10, 2013

Re: [Pharo-project] Zinc-WebSockets Live Demo

by Martin Dias

I installed and played a bit, it's cool!! thanks Martin On Wed, Jan 9, 2013 at 2:30 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Yesterday I deployed a live demo of Zinc-WebSockets > > http://websocket.stfx.eu > > Since most proxies and load balancers, most notably Apache, don't handle the WebSocket protocol very well, the only solution is to arrange for direct connections to the Smalltalk image. > > Deploying and running this code in your own image is pretty easy: > > ConfigurationOfZincHTTPComponents project latestVersion load: 'WebSocket'. > > ZnServer startDefaultOn: 1701. > ZnWebSocketDelegate installExamplesInDefaultServer. > > Then open http://localhost:1701/ws-demo with your browser. > > Sven > > PS: You can read more about Zinc-WebSockets here > > https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md > > PS: This demo, like the standard Zn and SSO demos run in the very latest Pharo 2.0 version > > http://zn.stfx.eu/status > http://sso.stfx.eu/status > http://websocket.stfx.eu:9999/status > http://websocket.stfx.eu:9999/ws-status-client > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Jan. 10, 2013

Re: [Pharo-project] Smalllint for Traits

by Frank Shearar

On 10 January 2013 08:17, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Thu, Jan 10, 2013 at 12:30 AM, aizcorbe > <juansebastian.aizcorbe(a)gmail.com> wrote: >> I have taken a look to pharo 2.0 and i didn't see omnibrowser there, is it >> going to be kept? Anyway the available smalllint implementation can be >> modified to let it check traits, but without all the omnibrowser extension. >> Btw... there are 14 smalllint traits rules implemented, including unit >> tests, but in the thesis there are identified a total of 36 traits errors, >> just in case someone what to take a look or implement them. > > > we don't plan to include omnibrowser in Pharo 2 as nobody is > maintaining it and we have Nautilus now. Still, we would be interested > in your rules and their integration inside Nautilus (there shouldn't > be too many things to change) The lint rules ought to be in a separate package so that both OmniBrowser and Nautilus folk could use and improve the same set of rules, shouldn't they? Each could have their own package hooking the rules up to the relevant UIs, of course. frank >> btw2... On my experience working with pharo and traits, i had many problems >> because it was usual to get errors on browsers, environments and others >> because they didn't handled traits properly. I think it would be nice if >> the environment tools didn't differenciate (whenever it makes sense) between >> classes and traits. In my thesis I propose the idea of behavior (since both >> define behavior) as a unifying entity for traits and classes. In this way, >> the environment tools would handle behaviors instead of just classes. > > I agree with you, a lot of work has to be done so that developers can > play with traits nicely. > > Thank you for your work and thesism I'm looking forward to read it > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Jan. 10, 2013

Re: [Pharo-project] Zinc-WebSockets Live Demo

by Norbert Hartl

Am 10.01.2013 um 10:02 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 09 Jan 2013, at 19:31, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Am 09.01.2013 um 16:11 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> Norbert, >>> >>> On 09 Jan 2013, at 14:57, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>>> Am 09.01.2013 um 14:30 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>>> Since most proxies and load balancers, most notably Apache, don't handle the WebSocket protocol very well, the only solution is to arrange for direct connections to the Smalltalk image. >>>> >>>> Who's interested in load balancing for websockets should look at HAProxy (http://haproxy.1wt.eu/) >>>> >>>> FYI, >>>> >>>> Norbert >>> >>> Yeah, I knew that HAProxy seems to be able to do it, but I didn't want to learn how to deal with the complexity of yet another technology stack. There is also the fundamental question whether it makes sense to proxy/tunnel the semi-permanent WebSocket connections. You would consume twice the resources while gaining little. >>> >> Agreed about yet another stack. But I don't think there is something like a fundamental question about those things. In my experience the first or second new requirement to your project always proves you wrong :) There are often use cases where it is inevitable to have a single entry point, have balancing even for TCP connections, pinning, etcâ¦ >> >>> Have you used HAProxy ? For WebSockets too ? >> >> I used HAProxy 5 years ago or so. But I'm referring to the experience of a friend of mine who actually uses it in production for http://www.userlike.de/. He uses Socket.IO for the chat connections and there are requirements he needs to use something like HAProxy. > > Cool. So you like HAProxy. Would you say it is easy to use compared to Apache ? > As I said, my experience with HAProxy is quite dated. It works great but what I remember it was quite hard to convince HAProxy to do what you want to. This situation should (!) have change in the meantime. At least there should be some documentation for certain use cases. HAProxy is widely used in installations so that would be my hope. Apart from that I'm glad my current stuff can be handled by nginx only and I don't have to use any of HAProxy, varnish, etcâ¦ These are all good pieces of software with an awful way of configuring it. And you need to know exactly for what purpose they are designed. At the end they are not very flexible that's why you have to find the right software that fits your needs. And when it comes to http every of those solves a distinct 5% of the overall puzzle. > Maybe I do have to try it when I have some time. > IMHO that is always a good idea if you set yourself a limited time frame for it. > If you would recommend it, what would be a good place to start, a good tutorial ? > I think it's best to wait for my friend to return from vacation (within the next days). I'll bug him them for the information and links and get to you back. >> Btw. my post wasn't meant to "you should use HAProxy". I just wanted to give some hints for people who feel they need for it. > > Yes, I understood it that way ;-) > Good :) Norbert

Jan. 10, 2013

Re: [Pharo-project] Zinc-WebSockets Live Demo

by Sven Van Caekenberghe

On 09 Jan 2013, at 19:31, Norbert Hartl <norbert(a)hartl.name> wrote: > Am 09.01.2013 um 16:11 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> Norbert, >> >> On 09 Jan 2013, at 14:57, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> Am 09.01.2013 um 14:30 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>>> Since most proxies and load balancers, most notably Apache, don't handle the WebSocket protocol very well, the only solution is to arrange for direct connections to the Smalltalk image. >>> >>> Who's interested in load balancing for websockets should look at HAProxy (http://haproxy.1wt.eu/) >>> >>> FYI, >>> >>> Norbert >> >> Yeah, I knew that HAProxy seems to be able to do it, but I didn't want to learn how to deal with the complexity of yet another technology stack. There is also the fundamental question whether it makes sense to proxy/tunnel the semi-permanent WebSocket connections. You would consume twice the resources while gaining little. >> > Agreed about yet another stack. But I don't think there is something like a fundamental question about those things. In my experience the first or second new requirement to your project always proves you wrong :) There are often use cases where it is inevitable to have a single entry point, have balancing even for TCP connections, pinning, etcâ¦ > >> Have you used HAProxy ? For WebSockets too ? > > I used HAProxy 5 years ago or so. But I'm referring to the experience of a friend of mine who actually uses it in production for http://www.userlike.de/. He uses Socket.IO for the chat connections and there are requirements he needs to use something like HAProxy. Cool. So you like HAProxy. Would you say it is easy to use compared to Apache ? Maybe I do have to try it when I have some time. If you would recommend it, what would be a good place to start, a good tutorial ? > Btw. my post wasn't meant to "you should use HAProxy". I just wanted to give some hints for people who feel they need for it. Yes, I understood it that way ;-)

Jan. 10, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Ciprian Teodorov

@Igor +1 On Jan 10, 2013 12:14 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > On 9 January 2013 20:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > Just wrap the assembler up in a string. But this low level shouldn't be > > necessary. If you went the compile-time route then you'd analyse the > call > > according to the platform's ABI and figure out the assembler > automatically. > > This is the architecture I was hoping yopu'd implement. If the > compilation > > step is left until the first call then the signatire becomes > > platform-independent. > > > > Assembler is absolutely necessary, because it is a developer who can > decide to use it, > not me. I just giving an opportunity. > This is a primary objective of NativeBoost project. > NativeBoost includes FFI implementation as integral part of it. > But that doesn't means that i should narrow it down only for this purpose. > > If i want to implement a primitive using brute-force assembler, it is > logical to put it in the source > of corresponding method, not somewhere else. > Also, since this is executable code, and does not requires separate > parser/compiler, > you are free to extensively practice a code-reuse, as in any smalltalk > code you write > (as well as make it platform independent, btw). > And so, users are free to mix assembler with own code, and there is > little or no constraints and canonical forms, to which everyone should > adhere. It is just plain smalltalk. > > > For a clunkier approach see my callback implementation where you build > up a > > library of transformers indexed by signature. The library contains > > different versions for each platform. If you applied this simple idea to > > the above you'd have some pragma somewhere which said "on x86 with > signature > > #( void (void * address, double aDouble) ) output this marshalling code: > > #(pop: EDX "load an...") etc. And then the call site would just supply > the > > signature. You'd get to share the marshalling code between functions > having > > the same signatures and you'd have a level of platform-independence. > > > > Wait.. Let us separate concerns. Platform-independence is orthogonal > to use (or not) use of pragmas in code. > > I do not see why i need to focus on platform independence right here right > now. > Does our beloved VM runs anywhere else than on 32-bit x86 CPUs? > Once there will be other options, trust me, i will be first who will > concentrate on making > things properly separated. > But when it is not , why i do even need to think/do something about it? > x64 using completely different call convention(s), not saying that > object format will > require some changes, and as result VM interface(s) as well.. > So, why i should constrain myself and introduce some "platform independece" > when i have no real thing at hand, so i don't even have a clue whether > my "platform-independent" > solution will will fit well with future VM/platform or not? > > Aside of it, right now, you can debug the code generation and see > everything from starting point > up to the end, using debugger just by stepping into method which uses NB > call. > You can see what happens, and see how your function signature turned > into real bytes which then fed to CPU. So, users can LEARN and improve > it. > Now if you split things , or even worse, move all logic at compile > time, you will make things opaque enough for debugging it and > understanding how it works. > Yes, this is good, if intent is to prevent a "regular" developer to > even think that he can directly use assembler. But my intent is > actually straightly opposite. > > My intent is to expose users to it. > I am perfectly fine with those who prefer to keep playing with plastic > toys without risk of hurting themselves. > But plastic world(s) has own limits, and so, if you want to reach outside, > then there is no magic, you have to stop playing in sandbox with > plastic toys, but instead grow up and take some risk and > responsibility. > And so, my philosophy (and NB as well) is to help people breaking out > and combine best of two worlds. > > Because, at the end, which code is more secure/safe: > - a well debugged and tested C code > - or a well debugged and tested smalltalk code > ? > > > -- > Best regards, > Igor Stasenko. > >

Jan. 10, 2013

Re: [Pharo-project] Smalllint for Traits

by Damien Cassou

On Thu, Jan 10, 2013 at 12:30 AM, aizcorbe <juansebastian.aizcorbe(a)gmail.com> wrote: > I have taken a look to pharo 2.0 and i didn't see omnibrowser there, is it > going to be kept? Anyway the available smalllint implementation can be > modified to let it check traits, but without all the omnibrowser extension. > Btw... there are 14 smalllint traits rules implemented, including unit > tests, but in the thesis there are identified a total of 36 traits errors, > just in case someone what to take a look or implement them. we don't plan to include omnibrowser in Pharo 2 as nobody is maintaining it and we have Nautilus now. Still, we would be interested in your rules and their integration inside Nautilus (there shouldn't be too many things to change) > btw2... On my experience working with pharo and traits, i had many problems > because it was usual to get errors on browsers, environments and others > because they didn't handled traits properly. I think it would be nice if > the environment tools didn't differenciate (whenever it makes sense) between > classes and traits. In my thesis I propose the idea of behavior (since both > define behavior) as a unifying entity for traits and classes. In this way, > the environment tools would handle behaviors instead of just classes. I agree with you, a lot of work has to be done so that developers can play with traits nicely. Thank you for your work and thesism I'm looking forward to read it -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Jan. 10, 2013

Re: [Pharo-project] Smalllint for Traits

by aizcorbe

I have taken a look to pharo 2.0 and i didn't see omnibrowser there, is it going to be kept? Anyway the available smalllint implementation can be modified to let it check traits, but without all the omnibrowser extension. Btw... there are 14 smalllint traits rules implemented, including unit tests, but in the thesis there are identified a total of 36 traits errors, just in case someone what to take a look or implement them. btw2... On my experience working with pharo and traits, i had many problems because it was usual to get errors on browsers, environments and others because they didn't handled traits properly. I think it would be nice if the environment tools didn't differenciate (whenever it makes sense) between classes and traits. In my thesis I propose the idea of behavior (since both define behavior) as a unifying entity for traits and classes. In this way, the environment tools would handle behaviors instead of just classes. cheers -- View this message in context: http://forum.world.st/Smalllint-for-Traits-tp4662559p4662687.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 9, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Igor Stasenko

On 9 January 2013 20:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Just wrap the assembler up in a string. But this low level shouldn't be > necessary. If you went the compile-time route then you'd analyse the call > according to the platform's ABI and figure out the assembler automatically. > This is the architecture I was hoping yopu'd implement. If the compilation > step is left until the first call then the signatire becomes > platform-independent. > Assembler is absolutely necessary, because it is a developer who can decide to use it, not me. I just giving an opportunity. This is a primary objective of NativeBoost project. NativeBoost includes FFI implementation as integral part of it. But that doesn't means that i should narrow it down only for this purpose. If i want to implement a primitive using brute-force assembler, it is logical to put it in the source of corresponding method, not somewhere else. Also, since this is executable code, and does not requires separate parser/compiler, you are free to extensively practice a code-reuse, as in any smalltalk code you write (as well as make it platform independent, btw). And so, users are free to mix assembler with own code, and there is little or no constraints and canonical forms, to which everyone should adhere. It is just plain smalltalk. > For a clunkier approach see my callback implementation where you build up a > library of transformers indexed by signature. The library contains > different versions for each platform. If you applied this simple idea to > the above you'd have some pragma somewhere which said "on x86 with signature > #( void (void * address, double aDouble) ) output this marshalling code: > #(pop: EDX "load an...") etc. And then the call site would just supply the > signature. You'd get to share the marshalling code between functions having > the same signatures and you'd have a level of platform-independence. > Wait.. Let us separate concerns. Platform-independence is orthogonal to use (or not) use of pragmas in code. I do not see why i need to focus on platform independence right here right now. Does our beloved VM runs anywhere else than on 32-bit x86 CPUs? Once there will be other options, trust me, i will be first who will concentrate on making things properly separated. But when it is not , why i do even need to think/do something about it? x64 using completely different call convention(s), not saying that object format will require some changes, and as result VM interface(s) as well.. So, why i should constrain myself and introduce some "platform independece" when i have no real thing at hand, so i don't even have a clue whether my "platform-independent" solution will will fit well with future VM/platform or not? Aside of it, right now, you can debug the code generation and see everything from starting point up to the end, using debugger just by stepping into method which uses NB call. You can see what happens, and see how your function signature turned into real bytes which then fed to CPU. So, users can LEARN and improve it. Now if you split things , or even worse, move all logic at compile time, you will make things opaque enough for debugging it and understanding how it works. Yes, this is good, if intent is to prevent a "regular" developer to even think that he can directly use assembler. But my intent is actually straightly opposite. My intent is to expose users to it. I am perfectly fine with those who prefer to keep playing with plastic toys without risk of hurting themselves. But plastic world(s) has own limits, and so, if you want to reach outside, then there is no magic, you have to stop playing in sandbox with plastic toys, but instead grow up and take some risk and responsibility. And so, my philosophy (and NB as well) is to help people breaking out and combine best of two worlds. Because, at the end, which code is more secure/safe: - a well debugged and tested C code - or a well debugged and tested smalltalk code ? -- Best regards, Igor Stasenko.

Jan. 9, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Eliot Miranda

On Wed, Jan 9, 2013 at 12:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 January 2013 19:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > > On Fri, Jan 4, 2013 at 12:37 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 4 January 2013 08:54, Torsten Bergmann <astares(a)gmx.de> wrote: > >> > When one deploys an image one usually requires ONLY > >> > the image - not the source or changes file. An "image locker" > >> > code would look like this: > >> > > >> > SmalltalkImage checkSourcesFileAvailability: false. > >> > SmalltalkImage checkChangesFileAvailability: false > >> > > >> > do disable acording warnings when source/changefile is removed. > >> > > >> > If one uses NativeBoost in such a deployment scenario, for > >> > instance the > >> > > >> > NBWin32Shell shellBrowse: 'http://www.google.de' > >> > > >> > functionality the internal code (due to missing source) now > >> > looks like this > >> > > >> > shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 > >> > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > >> > ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR > >> > #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR > >> > #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' > >> > > >> > Hence the t1 ... t5 parameters. > >> > > >> > NativeBoost is in this situation not able to match the > >> > FFI parameters and throws an error "Could not find accessor for > variable > >> > ..." > >> > > >> > Try yourself without a changes and source file. This makes > >> > NativeBoost not very deployment friendly and unusable in > >> > such a "minimal deployment" scenario ... > >> > > >> > Any comments? > >> > > >> > >> yes it needs sources (indirectly) to bind method's argument names > >> during code generation. > >> To avoid that, i can imagine that one must modify a compiler to detect > >> if compiled method > >> primitive requires arg names, and store them in method properties. > >> Like that later code generator can use them without need to access the > >> source code. > > > > > > Indeed. If a pragma were used then the whole thing could look a lot > nicer, > > not be dependent on source, and include support for an error code. e.g. > > > > shellExecute: lpOperation file: lpFile parameters: lpParameters > directory: > > lpDirectory show: nShowCmd > > > > <nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR > #lpOperation #, > > #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, > #INT > > #nShowCmd ) ) > > module: 'Shell32.dll' > > errorCode: ec> > > > > ^self nbCallFailedWith: ec > > > > It's pretty trivial to add such pragma compilers to the compiler. There > is > > an example for the FFI. It also frees one to use a nicer syntax, e.g. > > > > shellExecute: lpOperation file: lpFile parameters: lpParameters > directory: > > lpDirectory show: nShowCmd > > <nbCall: 'HINSTANCE ShellExecuteA(0, LPCTSTR lpOperation, LPCTSTR > > lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)' > > module: 'Shell32.dll' > > errorCode: ec> > > > > ^self nbCallFailedWith: ec > > > > i do not see how encoding function signature in pragma could help with > binding argument names. > Because your pragma processing code can add additional state, i.e. the map form input argument order to call argument order. > Yes, you need to get some control at compile time to be able to encode > method arg names somewhere in method properties for later use.. but > not at cost of moving everything into pragma. > What's this "cost"? The call info has to live somewhere. > > And 'nice' syntax is actually already there .. nothing prevents you > from using strings for function signature, e.g. > > self nbCall: 'int foo()' > equivalent to > self nbCall: #(int foo() ) > > (i don't know why Torsten gave code in such form, that could leave an > impression that syntax is horrible ;) > > And besides, how you suppose to "pragmatize" following: > > storeDouble: aDouble at: address > " This method stores a double floating point value at given memory > address. > an address can be an instance of NBExternalAddress, or > simple ByteArray with at least 8 bytes long, which will hold a > 64bit > floating-point value" > > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' > error: errorCode> > > ^ self nbCallout > options: #( > - optCoerceNilToNull > + optAllowByteArraysPtr > + optAllowExternalAddressPtr > ); > function: #( void (void * address, double aDouble) ) > emit: [:gen | | asm | > asm := gen asm. > > "Here , we expecting that an address value is on > top of the stack" > asm > pop: EDX; "load an address value into EDX > register by popping it > from a stack" > > "now copy the floating point value (which > is 8-bytes long) to the > given address" > mov: ESP ptr to: EAX; > mov: EAX to: EDX ptr; " store first 32bit > part of 64bit double value" > > mov: ESP ptr + 4 to: EAX; > mov: EAX to: EDX ptr + 4. " store second > 32bit part of 64bit double value" > > ] > Just wrap the assembler up in a string. But this low level shouldn't be necessary. If you went the compile-time route then you'd analyse the call according to the platform's ABI and figure out the assembler automatically. This is the architecture I was hoping yopu'd implement. If the compilation step is left until the first call then the signatire becomes platform-independent. For a clunkier approach see my callback implementation where you build up a library of transformers indexed by signature. The library contains different versions for each platform. If you applied this simple idea to the above you'd have some pragma somewhere which said "on x86 with signature #( void (void * address, double aDouble) ) output this marshalling code: #(pop: EDX "load an...") etc. And then the call site would just supply the signature. You'd get to share the marshalling code between functions having the same signatures and you'd have a level of platform-independence. -- best, Eliot

Jan. 9, 2013