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

Re: [Pharo-project] NativeBoost design and deployment

by Igor Stasenko

On 4 January 2013 09:51, Torsten Bergmann <astares(a)gmx.de> wrote: >> yes it needs sources (indirectly) to bind method's argument names >> during code generation. > > Sad. So this is currently a showstopper in using NB > in deployments where one would not like to give the > sources away. > > If we want (commercial) developers to write applications > in Pharo there should be a fix for that. > Yes. I don't like it either. It needs only the arg names (and their order) and for that, it involves a compiler to parse source and generate AST. Which can be completely avoided if temp names is stored somewhere after compilation. > Thanks > T. -- Best regards, Igor Stasenko.

Jan. 4, 2013

[Pharo-project] NativeBoost design and deployment

by Igor Stasenko

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

Jan. 4, 2013

[Pharo-project] NativeBoost design and deployment

by Torsten Bergmann

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? Thanks T.

Jan. 4, 2013

Re: [Pharo-project] [squeak-dev] Mine-able ideas?

by Igor Stasenko

On 3 January 2013 02:55, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Wed, Jan 02, 2013 at 05:26:25PM -0800, tim Rowledge wrote: >> >> On 02-01-2013, at 4:15 PM, "David T. Lewis" <lewis(a)mail.msen.com> wrote: >> > >> > Do you have a reference to the sensible compiled method format? I think >> > I recall some discussions on that topic, but I don't recall when or by >> > whom. >> >> I was thinking of the now-ancient 'NewCompiledMethod', going back to about 1997. The last I heard on the subject was about 5 years ago. > > Ah, right, it's all coming back to me now. Thanks. > >> But.. >> > >> > But really, what are we missing? We have CompiledMethodTrailer that appears to >> > provide an infinitely extensible mechanism for inventing new kinds of source >> > pointers. >> >> ? it reads as if that might provide the same result. Namely having the source pointer for each method be a proper oop, with all the obvious advantages over a weirdly encrypted 24bit number hidden within some bytes at the end of a byte array >> > > In principle, I think yes. Igor Stasenko created the CompiledMethodTrailer, > which has provided a really nice way to keep the existing formats working while > allowing all sorts of extensions. I'm not sure if he had in mind to implement > source pointers as first class objects, but it seems like it would be a > straightforward extension. > Sure thing, i wanted to go forward. I wrote about it multiple times. But we need someone who will put an idea into flesh :) > Cross posting to pharo in order to lure Igor back into the discussion ;-) > > Dave -- Best regards, Igor Stasenko.

Jan. 3, 2013

Re: [Pharo-project] PluggableMultiColumnListMorph example?

by Benjamin

Load the attached st file and execute the following snippet: (PluggableMultiColumnListMorph on: MyModelExample new list: #list selected: #selected changeSelected: #selected: menu: nil wrapSelector: #wrap:at:) openInWindow If you have questions, do not hesitate :) Ben On Jan 3, 2013, at 2:25 PM, J. P. L. MartÃn wrote: > Someone could give me a little example on PluggableMultiColumnListMorph? Does it work with OrderedCollections? > > Thanks in advance!

Jan. 3, 2013

[Pharo-project] PluggableMultiColumnListMorph example?

by J. P. L. MartÃn

Someone could give me a little example on PluggableMultiColumnListMorph? Does it work with OrderedCollections? Thanks in advance!

Jan. 3, 2013

Re: [Pharo-project] Extracting a ZipArchive in 2.0

by Vanessa PeÃ±a Araya

Ok, done. Thanks Stef. Vanessa. On 01/02/2013 04:18 PM, StÃ©phane Ducasse wrote: > On Jan 2, 2013, at 6:58 PM, Vanessa PeÃ±a Araya wrote: > >> Hi Camillo, >> >> Thank you for your reply. >> >> Yes, I understand, but I was wondering from the ZipArchive side. I mean, what I don't understand is if I'm using the wrong method (ZipArchive>>#extractAllTo:) or if ZipArchive is not updated to FileReference, or something else I'm not seeing :) > Probably that ZipArchive was not updates to FileReference so can you open an issue. > > Stef > > >> Thanks, >> Vanessa. >> >> On 12/28/2012 07:38 PM, Camillo Bruni wrote: >>> try to have a look at the other ensure* methods on FileReference or AbstractFileReference. >>> I think you need #ensureFile or #ensureDirectory :) >>> >>> On 2012-12-27, at 17:28, Vanessa PeÃ±a Araya <van.c.pena(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I want to extract a ZipArchive in Pharo 2.0, as the title says. I'm trying to do it with this: >>>> >>>> zipArchive >>>> extractAllTo: aDirectory >>>> informing: bar >>>> overwrite: false >>>> >>>> I'm trying the new file system but my problem is that ZipArchiveMember calls a method called "assureExistence", which does not exist... anywhere. >>>> >>>> Has anyone experience something like this? >>>> >>>> Thanks, >>>> Vanessa. >>>> >>> >> > >

Jan. 3, 2013

Re: [Pharo-project] [squeak-dev] Mine-able ideas?

by David T. Lewis

On Wed, Jan 02, 2013 at 05:26:25PM -0800, tim Rowledge wrote: > > On 02-01-2013, at 4:15 PM, "David T. Lewis" <lewis(a)mail.msen.com> wrote: > > > > Do you have a reference to the sensible compiled method format? I think > > I recall some discussions on that topic, but I don't recall when or by > > whom. > > I was thinking of the now-ancient 'NewCompiledMethod', going back to about 1997. The last I heard on the subject was about 5 years ago. Ah, right, it's all coming back to me now. Thanks. > But.. > > > > But really, what are we missing? We have CompiledMethodTrailer that appears to > > provide an infinitely extensible mechanism for inventing new kinds of source > > pointers. > > ? it reads as if that might provide the same result. Namely having the source pointer for each method be a proper oop, with all the obvious advantages over a weirdly encrypted 24bit number hidden within some bytes at the end of a byte array > In principle, I think yes. Igor Stasenko created the CompiledMethodTrailer, which has provided a really nice way to keep the existing formats working while allowing all sorts of extensions. I'm not sure if he had in mind to implement source pointers as first class objects, but it seems like it would be a straightforward extension. Cross posting to pharo in order to lure Igor back into the discussion ;-) Dave

Jan. 3, 2013

Re: [Pharo-project] [squeak-dev] Mine-able ideas?

by Frank Shearar

On 2 January 2013 22:17, Colin Putney <colin(a)wiresong.com> wrote: > > > > On Wed, Jan 2, 2013 at 4:18 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: >> >> http://blog.datomic.com/2012/10/codeq.html >> >> Executive summary: >> * Git gives version control over files >> * Clojure code typically has lots of functions or other chunks of code >> in one file >> * This means you can't ask for the version of a single unit of code >> * Static analyses over the files as they vary through time, dumped >> into a database, yields interesting stuff >> >> What they're calling "codeqs" ("code quantum") filetree folks would >> call a file, because filetree already splits everything (I think?) >> into bits, and versions everything at the "codeq" level by virtue of >> storing each bit in its own file: class definition, comment, method >> definition, etc. >> >> So we already have most of this stuff already - I couldn't live >> without my in-image method versions - but I'm wondering if anyone else >> can spot anything worth copying? > > > Nah. They're basically figuring out how to extract the semantic changes from > git, since git just treats the source code as opaque text. That gets them to > what Monticello has now. I guess there's a bit of "imagine what you could do > then!" that's unspecified. That was pretty much what I was thinking. And filetree preserves this fine-grained "code quantum"-sized version control. The only advantage I still see of lots-of-stuff-inna-file is that you can very quickly hop around a bunch of code. Our tools just don't work that way. They _could_. Noone's just ever hurt enough to display code in this fashion. It's easy enough: what's not so easy is to make that big blob of text efficiently editable such that you still keep track of the, for example, individual methods. (I'll leave aside the lack of syntax around method definition. That's not a big problem.) For instance: parse the entire file, find the method definitions, update the image by compiling them. (Handwave around the imperative hacks one could do.) > Which is not to say that it's a bad idea. I'd love to create a huge database > of, say, the update stream going back to the beginning, or the entire > contents of squeaksource. But... then what? > > Things that spring to mind immediately: > > - universal senders and implementors > - metrics like message sends per method or methods per class > - detection of package dependencies This would be a massive win. I took a bash a while ago at extending DependencyBrowser to work over one's package-cache to do this. I didn't get terribly far, probably largely to me being pretty ignorant about just about everything I needed to know. I have the half-completed work lying around. Maybe I should publish it somewhere! frank > - analysis of how long-lived packages change over time > - analysis of contribution and collaboration between coders > > and so on. > > But, what good is it? Might be interesting, maybe there's some research > papers to be written, but would it do us any good as a community? Would > there be useful tools that came out of it? Would it be worth the effort? > Hard to say. > > Colin > > >

Jan. 2, 2013

Re: [Pharo-project] Mine-able ideas?

by StÃ©phane Ducasse

What I want is - senders at a given point in the past - better method metadata - better migration from one version to anotherâ¦. Stef On Jan 2, 2013, at 10:18 PM, Frank Shearar wrote: > http://blog.datomic.com/2012/10/codeq.html > > Executive summary: > * Git gives version control over files > * Clojure code typically has lots of functions or other chunks of code > in one file > * This means you can't ask for the version of a single unit of code > * Static analyses over the files as they vary through time, dumped > into a database, yields interesting stuff > > What they're calling "codeqs" ("code quantum") filetree folks would > call a file, because filetree already splits everything (I think?) > into bits, and versions everything at the "codeq" level by virtue of > storing each bit in its own file: class definition, comment, method > definition, etc. > > So we already have most of this stuff already - I couldn't live > without my in-image method versions - but I'm wondering if anyone else > can spot anything worth copying? > > frank >

Jan. 2, 2013