October 2015 - Pharo-dev - lists.pharo.org

binary serialization

by Robert Withers

Does Pharo have stream classes to binary de/serialize an object, such that the protocol accepts an object as an argument and converts it to a byteArray? -- thanks, Robert

Oct. 13, 2015

Re: [Pharo-dev] Slack?

by Dimitris Chloupis

extremely, nothing comes remotely close. Pretty much every open source project has at least one channel in freenode.net, quakenet is very popular with gamers . #python has around 2000 people online at all times, #clojure 700 , #java 466 , #c++ 1000, #emacs 1000, there is even irc channels for computets back from the 80s like my first computer Amstrad CPC 6128 at #cpc etc Blender which the program I use the most has around 5 channels, Blender also is a bit special in that all the development effort is coordinated via irc meetings usually every Sunday where all main devs are required to attend , moderated by the project leader , and make decisions on how the project should proceed, which features should go in and when the releases should come out. The project leader then publishes the meeting notes on the website which is a summary of the irc chat. There are other projects that follow similar approach to their development too like mypaint and Gimp. On Tue, Oct 13, 2015 at 4:30 AM Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Just wondering. Is IRC still popular? > > Alexandre > > > > On Oct 6, 2015, at 1:03 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > Quite frankly, the reason why IRC is so extremely popular, is because it > does its job very well and has some very nice clients. I am active at > #Pharo because I use several IRC channels, #Blender , #C++ , #Opengl , > #MACOS , #unrealengine , #emacs , #blendercoders and #blenderpython. So the > incredible power of IRC is not its features, but its community. > > > > I dont have an issue giving a slack a try but I see no reason to. > > > > On Tue, Oct 6, 2015 at 6:05 PM Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > > 2015-10-06 11:41 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > >>>> I think it would be better than the IRC alternative, no matter how > > >>>> good your IRC client is. > > >>> > > >>> why? because is new? #irc is around since a lot and it has work fine > for many groups of different sizes. > > > > > > Ey! I know IRC and used it since BitchX and then mIRC! > > > > > > But it's not because it's new, it's because is prettier, in provides > > > nice integrations with other services (GitHub, CI, you name it), file > > > previews. > > > > I just found it has a Gateway so you can use your existing XMPP or IRC > > client to connect to it. > > > > So no need to stop using your beloved IRC client :) > > > > I'm trying to set it up. > > > > Regards! > > > > -- > > Esteban. > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Oct. 13, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Thierry Goubier

Hi Eliot, I believe everytime this comes up, it is not an issue of filetree making files too long for the filesystem, it is an issue of Pharo not being able to read or write a valid file for the filesystem. It is easy to "fix" filetree to workaround bugs in FilePlugin on Windows, but I'm not sure it's the right way to solve the problem ;) Simply because someone will hit it when reading a random, valid file one day. Thierry Le 13/10/2015 01:01, Eliot Miranda a Ã©crit : > Hi Nicolai, > > I have to say that the problem lies with the git integration. The > length of Smalltalk selectors is effectively unlimited and the language > encourages Kong descriptive names. Many (most?) unixes have a > limitation of 256 characters in any path element and a PATH_MAX that may > be as little as 1024. So the current architecture is, for me, way too > close to implementation limits. IMO a far better design would be to use > protocol names, all methods per protocol, eg Object.accessing or two > files per class (instance & class side) with methods ordered by > selector. Either of those, but especially the last, should give good > diff results in git but be well away from the implementation limit. The > one method per file, selector as file name approach is asking for trouble. > > _,,,^..^,,,_ (phone) > > On Oct 12, 2015, at 3:04 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > >> >> >> 2015-09-15 9:19 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>>: >> >> >> >> 2015-09-14 23:10 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>>: >> >> >> Thanks Nicolai, that's great! I'll merge in your changes. >> Which files do I need to look at? >> >> >> I changed (removed my code, added Marcels) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> >> I added (should be the same as in squeak vm repository) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> >> >> But my changes only about that code that already is in squeaks >> repository. >> >> If we want to merge some of the pharo-vm code into squeaks branch, we >> first need to wrap that code with some #ifdefs >> >> (For the win32 file/directory stuff, this would be code in >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> and >> platforms/Cross/plugins/FilePlugin/FilePlugin.h) >> >> Maybe Estaban should look at this, and tell which path he would >> follow to >> merge those changes. >> >> >> OK, these changes are now in pharos vm repository, .... >> >> >> but I just found another issue with long paths, squeak and pharo: >> >> This is a path from one github repository based package >> >> u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st >> >> Yes, pathlength is 282! But I think the problem is not the overall >> path name, but the length of the filename. >> >> On squeak, you can open and browse the parent directory in a FileList >> and even show the contents of the contained files. >> On Pharo, this does not work, because Pharos FileList uses a different >> method for accessing the file attributes. >> (the difference is, we call dir_EntryLookup, whereas (most) of Squeaks >> FileList methods just call dir_Lookup). >> >> But there are some methods in Squeak that call dir_EntryLookup and >> those are failing too. >> >> For example: >> >> "Creating a Stream and reading the contents works" >> (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') >> contents. >> >> "Creating a Stream and accessing the directory entry does not work" >> (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') >> directoryEntry >> " -> Error: file not in directory: >> initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st" >> >> >> nicolai >> >>

Oct. 13, 2015

updated Cryptography

by Robert Withers

I am attaching the .mcz as I am unsure where to publish it. I fixed a few issues (hex is lowercase and inputs to SecureRandom) and all tests pass green in the latest Pharo 5.0. Is there a good place for this to live? -- thanks, Robert

Oct. 13, 2015

Re: [Pharo-dev] really

by Robert Withers

That's good advice, Alexandre. thanks, Robert On 10/12/2015 09:27 PM, Alexandre Bergel wrote: > Define a small model, pick some examples and write unit tests. > > Alexandre > > >> On Oct 12, 2015, at 8:33 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> This is what I want to build. What do you suggest I do? >> >> Thanks, >> >> Robert >> <RabbitPhone+Business+Plan.pdf> >

Oct. 13, 2015

Re: [Pharo-dev] Slack?

by Alexandre Bergel

Just wondering. Is IRC still popular? Alexandre > On Oct 6, 2015, at 1:03 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Quite frankly, the reason why IRC is so extremely popular, is because it does its job very well and has some very nice clients. I am active at #Pharo because I use several IRC channels, #Blender , #C++ , #Opengl , #MACOS , #unrealengine , #emacs , #blendercoders and #blenderpython. So the incredible power of IRC is not its features, but its community. > > I dont have an issue giving a slack a try but I see no reason to. > > On Tue, Oct 6, 2015 at 6:05 PM Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2015-10-06 11:41 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > >>>> I think it would be better than the IRC alternative, no matter how > >>>> good your IRC client is. > >>> > >>> why? because is new? #irc is around since a lot and it has work fine for many groups of different sizes. > > > > Ey! I know IRC and used it since BitchX and then mIRC! > > > > But it's not because it's new, it's because is prettier, in provides > > nice integrations with other services (GitHub, CI, you name it), file > > previews. > > I just found it has a Gateway so you can use your existing XMPP or IRC > client to connect to it. > > So no need to stop using your beloved IRC client :) > > I'm trying to set it up. > > Regards! > > -- > Esteban. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 13, 2015

Re: [Pharo-dev] really

by Alexandre Bergel

Define a small model, pick some examples and write unit tests. Alexandre > On Oct 12, 2015, at 8:33 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > This is what I want to build. What do you suggest I do? > > Thanks, > > Robert > <RabbitPhone+Business+Plan.pdf> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 13, 2015

really

by Robert Withers

This is what I want to build. What do you suggest I do? Thanks, Robert

Oct. 12, 2015

Alien and FFI in Pharo

by Robert Withers

I want to get NIO sockets working using FFI, which I understand means Alien. I can't seem to load Alien from the Catalog. What do you suggest I do? -- thanks, Robert

Oct. 12, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Eliot Miranda

Hi Nicolai, I have to say that the problem lies with the git integration. The length of Smalltalk selectors is effectively unlimited and the language encourages Kong descriptive names. Many (most?) unixes have a limitation of 256 characters in any path element and a PATH_MAX that may be as little as 1024. So the current architecture is, for me, way too close to implementation limits. IMO a far better design would be to use protocol names, all methods per protocol, eg Object.accessing or two files per class (instance & class side) with methods ordered by selector. Either of those, but especially the last, should give good diff results in git but be well away from the implementation limit. The one method per file, selector as file name approach is asking for trouble. _,,,^..^,,,_ (phone) > On Oct 12, 2015, at 3:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-09-15 9:19 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >> >> 2015-09-14 23:10 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> Thanks Nicolai, that's great! I'll merge in your changes. Which files do I need to look at? >> >> I changed (removed my code, added Marcels) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> >> I added (should be the same as in squeak vm repository) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> >> >> But my changes only about that code that already is in squeaks repository. >> >> If we want to merge some of the pharo-vm code into squeaks branch, we >> first need to wrap that code with some #ifdefs >> >> (For the win32 file/directory stuff, this would be code in >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> and >> platforms/Cross/plugins/FilePlugin/FilePlugin.h) >> >> Maybe Estaban should look at this, and tell which path he would follow to >> merge those changes. > > OK, these changes are now in pharos vm repository, .... > > > but I just found another issue with long paths, squeak and pharo: > > This is a path from one github repository based package > > u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st > > Yes, pathlength is 282! But I think the problem is not the overall path name, but the length of the filename. > > On squeak, you can open and browse the parent directory in a FileList and even show the contents of the contained files. > On Pharo, this does not work, because Pharos FileList uses a different method for accessing the file attributes. > (the difference is, we call dir_EntryLookup, whereas (most) of Squeaks FileList methods just call dir_Lookup). > > But there are some methods in Squeak that call dir_EntryLookup and those are failing too. > > For example: > > "Creating a Stream and reading the contents works" > (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') contents. > > "Creating a Stream and accessing the directory entry does not work" > (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') directoryEntry > " -> Error: file not in directory: initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st" > > > nicolai > >

Oct. 12, 2015