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

Re: [Pharo-project] FileSystem inconsistency

by StÃ©phane Ducasse

+1 >> anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol. >> maybe for 3.0? > > yes definitely :). > > Jimmie, maybe you can open an issue on code.google.com/p/pharo/? > with a complete list of the methods you find confusing?

Jan. 8, 2013

Re: [Pharo-project] Spec news

by Frank Shearar

On 8 January 2013 18:12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Benjamin Van Ryseghem-2 wrote >> Why using a meaningless array when we could use object ? > > +1. This seems hard to use/understand. If we don't want to depend on > Morphic, let Spec define its own intention revealing messages. Or pull LayoutFrame out into a separate package. That Morphic depends on that new package doesn't matter at all; what matters is that LayoutFrame doesn't depend on Morphic. LayoutFrame's a nice simple class. frank

Jan. 8, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Eliot Miranda

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 > > Thanks > > T. > > > > -- > Best regards, > Igor Stasenko > > -- best, Eliot

Jan. 8, 2013

Re: [Pharo-project] FileSystem inconsistency

by Camillo Bruni

On 2013-01-08, at 18:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol. > maybe for 3.0? yes definitely :). Jimmie, maybe you can open an issue on code.google.com/p/pharo/? with a complete list of the methods you find confusing?

Jan. 8, 2013

Re: [Pharo-project] Spec news

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > Why using a meaningless array when we could use object ? +1. This seems hard to use/understand. If we don't want to depend on Morphic, let Spec define its own intention revealing messages. -- View this message in context: http://forum.world.st/Spec-news-tp4662445p4662524.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 8, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by GÃ¶ran Krampe

On 01/08/2013 06:26 PM, Casimiro de Almeida Barreto wrote: > Repository refuses connection. Works for me. Both anon or with my SH credentials. regards, GÃ¶ran

Jan. 8, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Casimiro de Almeida Barreto

Repository refuses connection. On 06-01-2013 14:22, Ciprian Teodorov wrote: > Happy new year everybody! > > I am pleased to announce today the initial release of TalkFFI. > > TalkFFI enables /automatic/ FFI generation for Smalltalk. > It uses libclang <http://clang.llvm.org> to parse *unmodified* C > header files and generate FFI bindings to c libraries. > For now it supports the generation of NativeBoost FFI bindings. > > The project is released under MIT license, and you can find it on the > smalltalkhub site. > http://smalltalkhub.com/#!/~CipT/TalkFFI > <http://smalltalkhub.com/#%21/%7ECipT/TalkFFI> > > Please do not hesitate send me your comments/critics/ideas. > > Best regards, > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com <mailto:ciprian.teodorov@gmail.com> > www.teodorov.ro <http://www.teodorov.ro>

Jan. 8, 2013

Re: [Pharo-project] FileSystem inconsistency

by Esteban Lorenzano

anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol. maybe for 3.0? On Jan 8, 2013, at 5:58 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-01-08, at 17:55, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 08.01.2013, at 17:07, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> >>> Hello, >>> >>> I was writing a small utility using FileSystem. I had never used FileSystem before. So I am browsing the code trying to learn where to start and how to use it. >>> >>> It took me a little while to learn to do something like: >>> fs := FileSystem store: (DiskStore activeClass createDefault). >> >> Why not >> >> fs := FileSystem disk. >> >> ?? >> >> or: >> >> reference := FileSystem disk referenceTo: '/foo/bar.txt'. > > or: > > '/foo/bar/plonk.txt' asFileReference > '/foo/bar' asFileReference > > > which creates a FileReference on the disk, the default

Jan. 8, 2013

Re: [Pharo-project] FileSystem inconsistency

by Camillo Bruni

On 2013-01-08, at 17:55, Max Leske <maxleske(a)gmail.com> wrote: > > On 08.01.2013, at 17:07, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > >> Hello, >> >> I was writing a small utility using FileSystem. I had never used FileSystem before. So I am browsing the code trying to learn where to start and how to use it. >> >> It took me a little while to learn to do something like: >> fs := FileSystem store: (DiskStore activeClass createDefault). > > Why not > > fs := FileSystem disk. > > ?? > > or: > > reference := FileSystem disk referenceTo: '/foo/bar.txt'. or: '/foo/bar/plonk.txt' asFileReference '/foo/bar' asFileReference which creates a FileReference on the disk, the default

Jan. 8, 2013

Re: [Pharo-project] FileSystem inconsistency

by Max Leske

On 08.01.2013, at 17:07, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Hello, > > I was writing a small utility using FileSystem. I had never used FileSystem before. So I am browsing the code trying to learn where to start and how to use it. > > It took me a little while to learn to do something like: > fs := FileSystem store: (DiskStore activeClass createDefault). Why not fs := FileSystem disk. ?? or: reference := FileSystem disk referenceTo: '/foo/bar.txt'. Cheers, Max > > It would be nice if there were an instance creation method like > FileSystem createDefault which would do the above. > > My utility was renaming some files. Once I had acquired a FileSystemDirectoryEntry instance I needed to examine the name. > > I see #basename and #fullName. As I browse other classes I see #childNamesAt: and #pathName, etc. > > I was just curious why #basename and not #baseName? I guess it's like "filename". It's easier to write without camel casing and it's usually used as a "single" word. > > Thanks. > > Jimmie >

Jan. 8, 2013