July 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Sebastian Tleye

Hi Phil Have you been using changeSets? I had the same problem once, i couldn't figure out what the problem was, but i think there is a problem in the sorter tool (and change sets). 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> > Hello, > > I've been loading all of those packages in order to build a full web stack > development image. > > Everything now loads fine and kind of works but... > > The image is really slowing down and the size is getting very large. > > Here is the current one: > > 332580684 29 jul 10:50 > Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image > > 300+ megs... > > I've been doing some development in there and started looking for why this > was getting so large and slow. > > I did a SpaceTally print analysis and imported the results in a > spreadsheet. > > Look at the top consumers, especially the Semaphore thing. It is way > beyond whatever was expected. There is something wrong there. > > There must be a leak of Points, MorphExtensions and I can't just figure > out why there are so many Floats. > > I've been running test suites for some of the packages (e.g. OpenDBX and > Glorp) and this may be the result. > > This image is kind of what one doing web dev would end up with. > > But then, it is very hard to get rid of that unwanted space. > > I am trying to build a system I can start using for business projects and > feel concerned about that memory growth very seriously. > > Any pointers (I chased some already but here, there are way too many > entries); > > Thx > > Phil > > > >

July 29, 2013

Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

Hello, I've been loading all of those packages in order to build a full web stack development image. Everything now loads fine and kind of works but... The image is really slowing down and the size is getting very large. Here is the current one: 332580684 29 jul 10:50 Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image 300+ megs... I've been doing some development in there and started looking for why this was getting so large and slow. I did a SpaceTally print analysis and imported the results in a spreadsheet. Look at the top consumers, especially the Semaphore thing. It is way beyond whatever was expected. There is something wrong there. There must be a leak of Points, MorphExtensions and I can't just figure out why there are so many Floats. I've been running test suites for some of the packages (e.g. OpenDBX and Glorp) and this may be the result. This image is kind of what one doing web dev would end up with. But then, it is very hard to get rid of that unwanted space. I am trying to build a system I can start using for business projects and feel concerned about that memory growth very seriously. Any pointers (I chased some already but here, there are way too many entries); Thx Phil

July 29, 2013

Re: [Pharo-users] Unix Domain Sockets

by Sven Van Caekenberghe

On 28 Jul 2013, at 17:20, Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Sun, Jul 28, 2013 at 01:12:41PM +0200, Sven Van Caekenberghe wrote: >> Since UDP sockets are currently also in the same class, I don't see a >> need for a separate class in the current design. > > Hi Sven. Agreed, as I wrote in the other mail about gaining experience with > IPv6 as well. OK >> Yes, the code is too cryptic/technical, a helper method or two would >> solve this. > > Done as per my newest blog post. Will add that when I create the issue. Yes, I've seen it. Good, that is what I meant. >>> Also, I'll be looking into the minor changes needed to support >>> SocketStream as well. >> >> Can you elaborate on that ? > > SocketStream has instance creation methods such as > openConnectionToHost:port:. To use Unix domain sockets, I imagine something > like openConnectionToIPCSocketPath:. Ah, OK, I understand. But there is SocketStream class>>#on: once you have your socket. That should be enough for testing client and server side. Once you validated it works, you could indeed add the #openConnectionToIPCSocketPath: convenience method. >> To add this, I would like some minimal tests as well (to be skipped on >> windows). > > I took a peek at SocketTest; the setUp method sets up a server socket, and > tests are run against this socket. This kinda like requires what is being > tested to be working in the first place? I understand your point, it is possible to have interesting theoretical discussions about unit tests, but a test that exercises the code is much better than none at all. If you don't like the setup of SocketTest, write your own test class, like DomainSocketTest. Tests are really important: they are live, validated documentation. Regarding the last blog post, does that mean that a VM change is now necessary or not ? Thanks for contributing ! Sven > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/

July 28, 2013

Where is the license agreement document?

by StÃ©phane Ducasse

I could not find it on http://pharo.gforge.inria.fr/ :( > Thanks. From there this link http://pharo.gforge.inria.fr/licenseDocuments/ > throws a 404. Stef

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by StÃ©phane Ducasse

super! Stef On Jul 28, 2013, at 5:11 PM, Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Sun, Jul 28, 2013 at 10:12:27AM +0200, St?phane Ducasse wrote: >> This is nice to see some progress on Socket. >> - What is the license of the code? >> - Do you want to give it to the community? > > Hi Stef. Yes, I'm happy for these changes to be folded into Pharo. I'll > file an entry into the issue tracker. The license of the code is MIT, to > match Pharo's. > > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/ > >

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by StÃ©phane Ducasse

thanks for the report apparently it got lost somewhere. On Jul 28, 2013, at 5:03 PM, Pierce Ng <pierce(a)samadhiweb.com> wrote: > Hi Igor, > > Thanks. From there this link http://pharo.gforge.inria.fr/licenseDocuments/ > throws a 404.

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by Pierce Ng

On Sun, Jul 28, 2013 at 01:12:41PM +0200, Sven Van Caekenberghe wrote: > Since UDP sockets are currently also in the same class, I don't see a > need for a separate class in the current design. Hi Sven. Agreed, as I wrote in the other mail about gaining experience with IPv6 as well. > Yes, the code is too cryptic/technical, a helper method or two would > solve this. Done as per my newest blog post. Will add that when I create the issue. > > Also, I'll be looking into the minor changes needed to support > > SocketStream as well. > > Can you elaborate on that ? SocketStream has instance creation methods such as openConnectionToHost:port:. To use Unix domain sockets, I imagine something like openConnectionToIPCSocketPath:. > To add this, I would like some minimal tests as well (to be skipped on > windows). I took a peek at SocketTest; the setUp method sets up a server socket, and tests are run against this socket. This kinda like requires what is being tested to be working in the first place? Cheers. -- Pierce Ng http://samadhiweb.com/blog/

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by Pierce Ng

On Sun, Jul 28, 2013 at 10:12:27AM +0200, St?phane Ducasse wrote: > This is nice to see some progress on Socket. > - What is the license of the code? > - Do you want to give it to the community? Hi Stef. Yes, I'm happy for these changes to be folded into Pharo. I'll file an entry into the issue tracker. The license of the code is MIT, to match Pharo's. Cheers. -- Pierce Ng http://samadhiweb.com/blog/

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by Pierce Ng

On Sun, Jul 28, 2013 at 04:59:32AM +0200, Igor Stasenko wrote: > On 28 July 2013 03:46, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > Maybe this is the wrong list to ask, but how do I contribute this to Pharo? > http://www.pharo-project.org/community/how-to-contribute Hi Igor, Thanks. From there this link http://pharo.gforge.inria.fr/licenseDocuments/ throws a 404. > About unix sockets: i see the changes is not really big and easy to integrate. > My only question regarding this, how do you think, maybe it make sense to have > a separate class for it, so users can tell: > > UnixSocket new > > instead of > > Socket newIPC I went for minimal change. As Socket already has newTCP and newUDP instance creation methods, I use newICP. Since the VM apparently also supports IPv6, I'd suggest to defer on creating separate classes until there is more experience using Unix domain *and* IPv6 TCP/UDP sockets, alongside current code that is using TCP/UDP over IPv4. > i also think that if socket creation failed, the code should throw an > error rather than return nil. Ditto, I followed current behaviour. Not quite Smalltalk-like, I agree. Cheers. -- Pierce Ng http://samadhiweb.com/blog/

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by Sven Van Caekenberghe

Hi Pierce, On 28 Jul 2013, at 03:46, Pierce Ng <pierce(a)samadhiweb.com> wrote: > Hello, > > I want to share that I wrote a blog post on using Unix domain sockets in > Pharo. > > http://samadhiweb.com/blog/2013.07.27.unixdomainsockets.html Cool. We need to integrate this: there is VM support for it and it works with minimal additions. Since UDP sockets are currently also in the same class, I don't see a need for a separate class in the current design. > The NetNameResolver bits can be made more Smalltalk-ish. Yes, the code is too cryptic/technical, a helper method or two would solve this. > Also, I'll be looking into the minor changes needed to support SocketStream as well. Can you elaborate on that ? > Maybe this is the wrong list to ask, but how do I contribute this to Pharo? To add this, I would like some minimal tests as well (to be skipped on windows). Sven > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/ -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

July 28, 2013