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

Re: [Pharo-users] Pharo image processing library

by Luc Fabresse

2015-06-30 9:34 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Tue, Jun 30, 2015 at 8:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > > 2015-06-25 18:41 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> > >> Hi, > >> > >> is there any image (as in picture) processing library in the likes of > >> Python's PIL(http://effbot.org/imagingbook/image.htm), > >> > >> or even (highly unlikely) something like OpenCV (http://opencv.org/)? > > > > > > Not that I know of. > > I was interested at one time with the same topic. > > > Juan Vuletich had a nice PhotoSqueak project (squeak 1 or 2?) > > > http://www.jvuletich.org/Squeak/PhotoSqueak/PhotoSqueakGallery/PhotoSqueakG… > > I ask Juan about this one, but apparently this is not open-source. > > > There is Smagick > > http://smalltalkhub.com/#!/~StefanReichhart/Smagick/ > > > > (not a library on its own, but an interface to imagemagick) > > > > I think there was another squeak/imagemagic project but I don't remember. > > > > It would be great to have something like imagemagick, but implemented > > entirely in smalltalk. > > There was some experiments done by Luc : > http://smalltalkhub.com/#!/~LucFabresse/OpenCV this repo only contains some highly experimental code that do not work anymore :-( Luc > > > There is also some basic image processing in VirtualGPU : > http://smalltalkhub.com/#!/~ronsaldo/VirtualGPU > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Jan BlizniÄenko

Sounds good, could I try it and run all those benchmarks etc. on it on my PCs? Jan Nicolai Hess wrote > Yes, the vm primitives, like I already told some messages above. > FilePrimitives ARE slow on windows. > > We may get better performance, if we disable windows file cache/buffering > and use slightly different ways to do the CreateFile and WriteFile > calls, and do the buffering on our own, but this is not easy. > > Luckily (?), this may be alread work if we use the std file api (?) > > A small dirty test: > > store bench > latest vm -> '22.098 per second' > modified vm -> '31,027 per second' > > (in the modified vm I replaced all file operation from > sqWin32FilePrims.c > with the code from > sqFilePluginBasicPrims.c) > > The result may seem strange, because both implementation will actually use > win32s CreateFile/WriteFile methods, but > maybe the second one uses better caching/buffering. > > nicolai -- View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by David T. Lewis

On Wed, Jul 01, 2015 at 01:39:25AM +0200, Nicolai Hess wrote: > 2015-07-01 0:39 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > Then the only thing I can think of is a vm primitive that is implemented > > differently in linux/mac than windows vm... > > > > Yes, the vm primitives, like I already told some messages above. > FilePrimitives ARE slow on windows. Is that actually true? I have not done any work on Windows in a while, but I recall that file primitives on Windows were quite efficient. They work differently because they operate at the level of direct file handles rather than stdio streams, but this may be faster in many cases. So unless you have measurable evidence that the Windows IO is slower, don't assume it to be true. Dave

July 1, 2015