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

[Pharo-project] broken builds
by Camillo Bruni Jan. 4, 2013

Jan. 4, 2013

looks like the latest image/vm combination makes the command-line fail... On the Ci server I cannot run any command-line tools anymore with the latest.zips :/ On the Mac: - latest stack VM fails to open latest 20 image - latest cog VM fails to open latest 20 image - latest pharo VM fails to open latest 20 image with an older cog VM I can open the image without issues: Smalltalk vm version 'CoInterpreter VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Jul 26 2012 saving the image with the old VM immediately makes it work with the latest vms :?

1 0

Re: [Pharo-project] NativeBoost design and deployment
by Igor Stasenko Jan. 4, 2013

Jan. 4, 2013

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.

2 1

[Pharo-project] NativeBoost design and deployment
by Torsten Bergmann Jan. 4, 2013

Jan. 4, 2013

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.

1 0

Re: [Pharo-project] [squeak-dev] Mine-able ideas?
by David T. Lewis Jan. 3, 2013

Jan. 3, 2013

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

2 1

[Pharo-project] Extracting a ZipArchive in 2.0
by Vanessa PeÃ±a Araya Jan. 3, 2013

Jan. 3, 2013

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.

3 4

Re: [Pharo-project] [squeak-dev] Mine-able ideas?
by Frank Shearar Jan. 2, 2013

Jan. 2, 2013

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 > > >

1 0

[Pharo-project] Mine-able ideas?
by Frank Shearar Jan. 2, 2013

Jan. 2, 2013

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

2 1

[Pharo-project] [ENH]: MCHttpRepository Authentication (Issue 6449)
by Sean P. DeNigris Jan. 2, 2013

Jan. 2, 2013

http://code.google.com/p/pharo/issues/detail?id=6449 We should be able to say, "MCHttpRepository logInto: serverUrl as: username withPassword: passwordString" Is there any use case for not using the server credentials with a particular repo i.e. myserver/ss has credentials, but myserver/ss/myrepo uses different/no credentials? If we assume that all repos with a given prefix will use the same credentials, the implementation will be much simpler... Conversation-starter in the inbox. Please take a look and comment, but do not integrate. Name: SLICE-Issue-6449-ENH-MCHttpRepository-Authentication-SeanDeNigris.1 Hack together an implementation to start the conversation. ***This should NOT be integrated*** -- View this message in context: http://forum.world.st/ENH-MCHttpRepository-Authentication-Issue-6449-tp4641… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 4

[Pharo-project] corrupt images on gforge
by Camillo Bruni Jan. 2, 2013

Jan. 2, 2013

see http://code.google.com/p/pharo/issues/detail?id=7196 I suggest someone other than me fixes it ;) to - add missing documentation - see how complicated everything is

3 2

Jan. 2, 2013

Hi all alert:, alert:title:... are defined on MorphicUIManager but not on NonInteractiveUIManager so this means that we get DNU when loading packages that call it. http://code.google.com/p/pharo/issues/detail?id=7205 I thought that bringing a pop up or dun in non interactive mode was killing the system but not. I'm confused but any how it would be good to have these two classes a bit more polymorphic so tell me if I'm saying something stupid. Stef

3 3