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

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. Tests.System.OSEnvironmentTest.testAtPut

May 5, 2013

Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Esteban Lorenzano

yeah, what I did was bypass the type checking, not a really solution... we need something better. On May 5, 2013, at 12:18 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I remember Esteban had some similar problem when working on the ObjCBridge... Esteban? :D > > > On Sun, May 5, 2013 at 12:14 PM, Max Leske <maxleske(a)gmail.com> wrote: > I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy. > > Here's my use case: > > self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) > > This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so: > > self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) > > But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. > Being able to use a superclass would just be awesome! > > Cheers, > Max >

May 5, 2013

Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Max Leske

BTW, here's a hack to get it working with one method only: {#git_return_t. #git_object_lookup. {object className asSymbol. #*. #object. #,. #git_repository_ptr. #repo. #,. #git_oid_ptr. #id. #,. #git_otype. #type}} :P On 05.05.2013, at 12:18, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I remember Esteban had some similar problem when working on the ObjCBridge... Esteban? :D > > > On Sun, May 5, 2013 at 12:14 PM, Max Leske <maxleske(a)gmail.com> wrote: > I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy. > > Here's my use case: > > self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) > > This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so: > > self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) > > But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. > Being able to use a superclass would just be awesome! > > Cheers, > Max >

May 5, 2013

Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Guillermo Polito

I remember Esteban had some similar problem when working on the ObjCBridge... Esteban? :D On Sun, May 5, 2013 at 12:14 PM, Max Leske <maxleske(a)gmail.com> wrote: > I have a wish for NativeBoost (which is probably on your list anyway Igor, > just wanted to put it out there): function definitions should be able to > understand that I want to accept any object of a hierarchy. > > Here's my use case: > > self call: #(git_return_t git_object_lookup(LGitCommitExternal * > object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) > > This function takes a pointer to any of LGitCommitExternal, > LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this > was to create a superclass LGitObjectExternal and use that superclass in > the function like so: > > self call: #(git_return_t git_object_lookup(LGitObjectExternal * > object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) > > But that gives me an error. So for now I can either use a dummy object > (like NBExternalObject) and then convert from that or I have to implement > the same function thrice in the different object flavors. > Being able to use a superclass would just be awesome! > > Cheers, > Max >

May 5, 2013

[Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Max Leske

I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy. Here's my use case: self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so: self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. Being able to use a superclass would just be awesome! Cheers, Max

May 5, 2013

Re: [Pharo-project] [Help-smalltalk] Fun with Pharo generated source.st

by Frank Shearar

On 5 May 2013 09:54, Paolo Bonzini <bonzini(a)gnu.org> wrote: > Il 04/05/2013 18:51, Holger Hans Peter Freyther ha scritto: >> Hi, >> >> I am trying to convert/import all of Iliad (since the development had >> moved to Pharo) and I stumble up-on an issue I already had when I tried >> to convert Aida. >> >> This[1] monticello file in line 6417 starts to use UCS-4 for a string >> and then stops at some characters later. Importing the file using >> FileStream is failing in Pharo as well. > > And how does monticello file it in then?!? I'm adding the Pharo list. Monticello doesn't use the snapshot. The snapshot's stored in addition to the "real" MC stuff, containing the changes that the mcz defines. It's sorta-kinda like the difference between your working copy and git diff HEAD HEAD^. MC uses the latter, the snapshot is the former. frank > Paolo > >> There doesn't appear to be a BOM before the UCS-4 so I wonder if we >> can detect it or not. Maybe it is time to use more of MontiCello to >> read these files directly. >> >> ideas? >> >> holger >> >> >> >> [1]http://www.squeaksource.com/IliadDev/Iliad-Core0.9.1-SebastienAudier.5.mcz >> >> _______________________________________________ >> help-smalltalk mailing list >> help-smalltalk(a)gnu.org >> https://lists.gnu.org/mailman/listinfo/help-smalltalk >> > >

May 5, 2013

[Pharo-project] [update 3.0] #30104

by Marcus Denker

â¦ will be online as soon as github is working again 30104 ----- 6161 DiskStore>>directoryAt:ifAbsent:nodesDo: https://pharo.fogbugz.com/f/cases/6161 10460 Spec - InputWidget >> ok https://pharo.fogbugz.com/f/cases/10460 10523 clean up #parseArgsAndTemps:notifying: https://pharo.fogbugz.com/f/cases/10523 10524 StartupPreferences interferes with zeroconf pharo binary https://pharo.fogbugz.com/f/cases/10524 10526 Typo in CommandLineHandler >> #exitFailure: https://pharo.fogbugz.com/f/cases/10526 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/StartupPreferences-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.141… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Memory-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Disk-MarcusDenker.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.438.diff

May 5, 2013

Re: [Pharo-project] [Help-smalltalk] Fun with Pharo generated source.st

by Paolo Bonzini

Il 04/05/2013 18:51, Holger Hans Peter Freyther ha scritto: > Hi, > > I am trying to convert/import all of Iliad (since the development had > moved to Pharo) and I stumble up-on an issue I already had when I tried > to convert Aida. > > This[1] monticello file in line 6417 starts to use UCS-4 for a string > and then stops at some characters later. Importing the file using > FileStream is failing in Pharo as well. And how does monticello file it in then?!? I'm adding the Pharo list. Paolo > There doesn't appear to be a BOM before the UCS-4 so I wonder if we > can detect it or not. Maybe it is time to use more of MontiCello to > read these files directly. > > ideas? > > holger > > > > [1]http://www.squeaksource.com/IliadDev/Iliad-Core0.9.1-SebastienAudier.5.mcz > > _______________________________________________ > help-smalltalk mailing list > help-smalltalk(a)gnu.org > https://lists.gnu.org/mailman/listinfo/help-smalltalk >

May 5, 2013

Re: [Pharo-project] Zeroconf and OS string

by Norbert Hartl

Am 05.05.2013 um 10:44 schrieb "phil(a)highoctane.be" <phil(a)highoctane.be>: > on Mobaxterm the output of uname -a is > > [Philippe.DELLGFX] â uname -a > CYGWIN_NT-6.1-WOW64 DELLGFX 1.7.17(0.262/5/3) 2012-10-28 12:24 i686 GNU/Linux > > > Clearly no Windows in there. > Hmm, I think you are running Windows 7 on a Dell laptop :) CYGWIN_NT-6.1 should be windows enough in there, right? CYG is a good information and the rest you can look up at http://en.wikipedia.org/wiki/Windows_NT_6.1 Norbert

May 5, 2013

Re: [Pharo-project] How to "fix" "broken" mcz files?

by Norbert Hartl

Am 05.05.2013 um 10:07 schrieb Holger Hans Peter Freyther <holger(a)freyther.de>: > Hi, > > when I port a project to GNU Smalltalk I tend to use the snapshot/*.st > and convert it. Now with some MCZ versions of Aida/Iliad this is failing > because the fileout is broken. The fileout is broken in a way that at > some point (without a BOM) the creator started to use UCS-4 (or such) for > the strings. > > This can be seen here[1] and either manually extracting the source and > using FileStream>>#fileIn: or by using the MczInstaller on the mcz file > (which is not working on the snapshot of the MCDefinition) the import > will fail. > > Is this a known/fixed problem with Monticello/Pharo? Is there a way to > re-create the source.st from the snapshot of the MCDefinitions? > Yes, the problem is known. Monticello has no handling for encoding. The last time I looked into it I could see that Monticello is assuming a latin1 encoding. As soon as you include a non-latin1 character in the source it will be turned into a WideString. When this is written to disk either our UCS-4+leadingChar format is written or even worse in way that every byte of a WideString is latin1 encoded then. I'm not sure in any way it isn't the right way to do it. I started to fix this a couple of years ago but as most of the time the problem is deeply embedded in the image and grows the longer you look at it. And that exceeds my time frame I have for these things massively. The problem is easier to fix for the .st file because in case of String representations ('') or the usage of the String class it is platform independent. In the binary blob the platform specific classes like WideString appear that make it unreadable on other platforms. Here the canonical way of encoding something in utf-8 would also mean that platform dependent class are treated in the same canonical way to use only String instead of platform dependent ones. A platform that reads a monticello file gets utf-8 decodes it and then on occurrence of a wide character would then turn it into a platform dependent class, etc. So, in order to "fix" this I think the only feasible way is to get rid of non-latin1 characters in the source and save the package again. This is how it is done, e.g. in seaside. If someone really needs some non latin1 characters they should be included programmatically, meaning at the right position in code use "Character value: â¦" Norbert

May 5, 2013