- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Many problems with Iceberg :-(

by Nicolas Passerini

Hi Alex, I'm sorry I missed your last message on Slack. Yes, current "stable" version (v0.2.1) has a bug, that I decided not to fix because I am about to release v0.3. The new version is quite stable and a lot faster, so maybe you will like to give it a test before the release (that should be in a few days anyway. It seems that you have loaded code from Monticello but at the same time you have the same packages in an Iceberg repository. Am I right? If that is the case, I have to say we do not support exactly that usage pattern. Sorry, for that, I will work on supporting it. In the meanwhile, you have a few workarounds: 1) If your code is already in a git repository (I guess it is the case given your error), then loading it in a clean image should not pose any problems. 2) Or if you loaded from github using metacello it should also work (I would say it should work also for code loaded from gitfiletree but Norbert reported a problem with it, which I am not being able to reproduce.) 3) Otherwise, if your code is only in monticello, then saving it to a clean Iceberg repository should work also. In any case, do not hesitate comming to me with any question or problem, I will try to help you. (But take into account the different time zones.) Cheers, Nico On Fri, Sep 23, 2016 at 5:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Please use the development version of Iceberg. It should be fixed there. > > Metacello new > baseline: 'Iceberg'; > repository: 'github://npasserini/iceberg'; > load. > > Cheers, > Doru > > > > On Sep 23, 2016, at 12:07 AM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > > Hi! > > > > I am facing several bugs using Iceberg. > > Am I the only one? > > > > <Screen Shot 2016-09-22 at 7.06.08 PM.png> > > <Screen Shot 2016-09-22 at 7.06.18 PM.png> > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > > > >

Sept. 23, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] d3c4dd: 60236

by Tudor Girba

Great addition! Doru > On Sep 23, 2016, at 8:25 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> >> 19124 enhance Deprecation to log sending method >> https://pharo.fogbugz.com/f/cases/19124 > > > The result of this is that now the log on the CI now exactly tells us what to fix: > (I will add issue tracker entries for each): > > *** Warning: Deprecation: The method GTSpotter>>isEmpty called from GTSpotterTest>>#testNewSpotter has been deprecated. > Use hasSteps instead > > *** Warning: Deprecation: The method Object>>name called from KMRepository>>#addCategory: has been deprecated. > Implement your own domain representation of an object, or use #asString or #printString instead. > > *** Warning: Deprecation: The method Object>>name called from ClassHierarchyTest>>#testSubclasses has been deprecated. > Implement your own domain representation of an object, or use #asString or #printString instead. > > *** Warning: Deprecation: The method Object>>name called from BooleanSlot>>#layoutChanged: has been deprecated. > Implement your own domain representation of an object, or use #asString or #printString instead. > > *** Warning: Deprecation: The method Object>>name called from GlobalVariableTest>>#testSmalltalkNotDoubleSymbol has been deprecated. > Implement your own domain representation of an object, or use #asString or #printString instead. > > *** Warning: Deprecation: The method Object>>name called from PropertySlot>>#layoutChanged: has been deprecated. > Implement your own domain representation of an object, or use #asString or #printString instead. > > *** Warning: Deprecation: The method Object>>name called from UnlimitedInstanceVariableSlot>>#layoutChanged: has been deprecated. > Implement your own domain representation of an object, or use #asString or #printString instead. > > *** Warning: Deprecation: The method Object>>name called from ChangeSet>>#changeRecorderFor: has been deprecated. > Implement your own domain representation of an object, or use #asString or #printString instead. > > -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

Sept. 23, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] d3c4dd: 60236

by Marcus Denker

> > 19124 enhance Deprecation to log sending method > https://pharo.fogbugz.com/f/cases/19124 The result of this is that now the log on the CI now exactly tells us what to fix: (I will add issue tracker entries for each): *** Warning: Deprecation: The method GTSpotter>>isEmpty called from GTSpotterTest>>#testNewSpotter has been deprecated. Use hasSteps instead *** Warning: Deprecation: The method Object>>name called from KMRepository>>#addCategory: has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead. *** Warning: Deprecation: The method Object>>name called from ClassHierarchyTest>>#testSubclasses has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead. *** Warning: Deprecation: The method Object>>name called from BooleanSlot>>#layoutChanged: has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead. *** Warning: Deprecation: The method Object>>name called from GlobalVariableTest>>#testSmalltalkNotDoubleSymbol has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead. *** Warning: Deprecation: The method Object>>name called from PropertySlot>>#layoutChanged: has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead. *** Warning: Deprecation: The method Object>>name called from UnlimitedInstanceVariableSlot>>#layoutChanged: has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead. *** Warning: Deprecation: The method Object>>name called from ChangeSet>>#changeRecorderFor: has been deprecated. Implement your own domain representation of an object, or use #asString or #printString instead.

Sept. 23, 2016

Re: [Pharo-dev] C Variadic Functions via UFFI?

by Andres Valloud

I wouldn't do that if I were you. The manual says fcntl() can be a macro, and you can't call a macro from an FFI. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/fcntl.h.html On 9/22/16 15:12 , Mariano Martinez Peck wrote: > Hi guys, > > I am wondering if I can wrap some variadic functions (with optional > arguments) with UFFI. Is this possible? If true, how so? For my > particular use case, I am checking if I can call fcntl() > which has a third optional argument. > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com

Sept. 23, 2016

Re: [Pharo-dev] Many problems with Iceberg :-(

by Tudor Girba

Hi, Please use the development version of Iceberg. It should be fixed there. Metacello new baseline: 'Iceberg'; repository: 'github://npasserini/iceberg'; load. Cheers, Doru > On Sep 23, 2016, at 12:07 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > I am facing several bugs using Iceberg. > Am I the only one? > > <Screen Shot 2016-09-22 at 7.06.08 PM.png> > <Screen Shot 2016-09-22 at 7.06.18 PM.png> > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Sept. 23, 2016

C Variadic Functions via UFFI?

by Mariano Martinez Peck

Hi guys, I am wondering if I can wrap some variadic functions (with optional arguments) with UFFI. Is this possible? If true, how so? For my particular use case, I am checking if I can call fcntl() which has a third optional argument. Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Sept. 23, 2016

Many problems with Iceberg :-(

by Alexandre Bergel

Hi! I am facing several bugs using Iceberg. Am I the only one? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 23, 2016

Re: [Pharo-dev] error: cannot find OpenSSL or Libgcrypt when creating the VM on OSX

by Mariano Martinez Peck

Hi Alex, I was having the same issue since a long time. And I always have to workaround as Esteban suggested (explicitly removing the libssh2 third party). But that was painful as I wanted a running out of the box situation. I tried a couple of things and none worked until I run the following from command line: xcode-select --install That allowed me to install/update command line tools from Xcode and that made it work. Cheers, On Tue, Mar 1, 2016 at 9:50 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > you have a dependency conflict. > but most probably you do not need those plugins. Why do you want to build > VM by your own? > > In any case, you can just remove those dependencies for you buildâ¦ after > if you need it you can check what conflicts: > > buildMacOSX32 > "Build with freetype, cairo, osprocess" > PharoSpur32OSXConfig new > generationType: generationType; > addExternalPlugins: #( FT2Plugin ); > addInternalPlugins: #( UnixOSProcessPlugin ); > addThirdpartyLibraries: #( > 'cairo' > âlibgit2â > 'libssh2' > 'libsdl2'); > generateSources; > generate. > > you can remove all the third party libraries section. > > Esteban > > > On 28 Feb 2016, at 22:32, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > > Here is the trace of the build.sh > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > checking for _FILE_OFFSET_BITS value needed for large files... no > > checking for ld used by GCC... /Applications/Xcode.app/ > Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld > > checking if the linker (/Applications/Xcode.app/ > Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU > ld... no > > checking for shared library run path origin... done > > checking for libssl... no > > checking for libgcrypt... no > > configure: error: cannot find OpenSSL or Libgcrypt, > > try --with-libssl-prefix=PATH or --with-libgcrypt-prefix=PATH > > make[2]: *** [thirdParty/libssh2/src/libssh2-stamp/libssh2-configure] > Error 1 > > make[1]: *** [thirdParty/libssh2/CMakeFiles/libssh2.dir/all] Error 2 > > make: *** [all] Error 2 > > ~/Desktop/VM_TMP/pharo-vm/build> brew install OpenSSL > > Warning: openssl-1.0.2a-1 already installed > > ~/Desktop/VM_TMP/pharo-vm/build> brew install Libgcrypt > > ==> Downloading ftp://ftp.gnupg.org/gcrypt/ > libgcrypt/libgcrypt-1.6.3.tar.bz2 > > Already downloaded: /Library/Caches/Homebrew/libgcrypt-1.6.3.tar.bz2 > > ==> ./configure --disable-silent-rules --prefix=/usr/local/Cellar/ > libgcrypt/1.6. > > ==> make > > ==> make check > > > > Please report to http://bugs.gnupg.org > > ====================================== > > make[2]: *** [check-TESTS] Error 1 > > make[1]: *** [check-am] Error 2 > > make: *** [check-recursive] Error 1 > > > > READ THIS: https://git.io/brew-troubleshooting > > > > ~/Desktop/VM_TMP/pharo-vm/build> > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > > > > > > > > > ~/Desktop/VM_TMP/pharo-vm/build> gcc --version > > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/Applications/Xcode.app/ > Contents/Developer/Platforms/MacOSX.platform/Developer/ > SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 > > Apple LLVM version 7.0.2 (clang-700.1.81) > > Target: x86_64-apple-darwin15.2.0 > > Thread model: posix > > ~/Desktop/VM_TMP/pharo-vm/build> > > > > > > > > No idea whatâs going onâ¦ > > Help :-) > > > > Alexandre > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 22, 2016

Re: [Pharo-dev] ZnPortNotANumber exception when loading from local clone dir (following Metacello Guide)

by Thierry Goubier

Le 22/09/2016 Ã 20:53, Dale Henrichs a Ã©crit : > > > On 09/22/2016 12:41 AM, Sven Van Caekenberghe wrote: >>> On 22 Sep 2016, at 00:19, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> Hi Sven, >>> >>> thanks. Did not notice that I need three instead of two slashes. So >>> no need >>> to explicitly convert to ZnUrl. >>> >>> So for the records this is what works: >>> >>> >>> pathToPackageDirectory := 'C:\ClonedRepo\packages'. >>> Metacello new >>> baseline: 'MyProject'; >>> repository: ('gitfiletree:///', pathToPackageDirectory) ; >>> load. >> So mixing back & forward slashes works ? Pretty weird ;-) > Yes that is interesting ... in Metacello for Pharo, `('/', > pathToPackageDirectory ) asFileReference` (stripping the leading > 'filetree://') is being used to create the FileTree repository from the > repository description ... so apparently this is how FileSystem deals > with windows pathnames ??? > > Oh wait, that is a gitfiletee url ... not sure how that is handles ... GitFileTree has a copy(*) of the ZnUrl code for extracting file references out of urls, so it may differ from Filetree / Metacello (see MCFileTreeGitRepository>>#urlAsFileReference:). Oh, ok. FileTree has the same method, but with a correction for what must have been a bug in the GitFileTree method (need to have a look at that), however, Metacello does not use that method for a filetree:// url. Checked in Pharo 6. Thierry (*) Copy because extending ZnUrl wasn't possible without an override. I kind of agree with the Go philosophy there: sometimes, a little bit of copy/paste makes everything simpler. > Dale >> >>> Thanks >>> T. >>> >>>> Gesendet: Dienstag, 20. September 2016 um 20:41 Uhr >>>> Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>> Betreff: Re: [Pharo-dev] ZnPortNotANumber exception when loading >>>> from local clone dir (following Metacello Guide) >>>> >>>> Hi Torsten, >>>> >>>> Just for the ZnUrl part, have a look at >>>> >>>> ZnFileUrlTests>>#testWindowsDriveNamesInFileUrl >>>> >>>> AFAIK, your example should be written as: >>>> >>>> ('filetree:///' , 'C:/ClonedRepo/packages') asZnUrl. >>>> >>>> Or maybe, >>>> >>>> (FileLocator C / 'ClonedRepo' / 'packages') asZnUrl. >>>> >>>> Sven >>>> >>>>> On 20 Sep 2016, at 20:30, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> >>>>> Hi, >>>>> >>>>> according to the Metacello quide on [1] in section "Prime Metacello >>>>> registry" one can write >>>>> >>>>> | pathToPackageDirectory | >>>>> "edit to match the path to your chosen package directory" >>>>> pathToPackageDirectory := '/opt/git/Sample/packages'. >>>>> Metacello new >>>>> baseline: 'Sample'; >>>>> repository: 'filetree://', pathToPackageDirectory; >>>>> load. >>>>> >>>>> Adopting this for a Windows path I have: >>>>> >>>>> | pathToPackageDirectory | >>>>> pathToPackageDirectory := 'C:\ClonedRepo\packages'. >>>>> Metacello new >>>>> baseline: 'MyProject'; >>>>> repository: 'filetree://', pathToPackageDirectory; >>>>> load. >>>>> >>>>> But I get a ZnPortNotANumber exception, even when I use a diffent >>>>> protocol like "client://". >>>>> Tried this in Pharo 6.0 Latest update: #60233 >>>>> >>>>> What I want to do (on Windows) is to load all project packages from >>>>> a local cloned git >>>>> directory (not a remote GitHub) using the dependencies given in the >>>>> Baseline. >>>>> >>>>> Did I miss something, is it just broken or the docu not up to date? >>>>> If so is this a parsing issue on the Zinc URLs >>>>> or an issue of Metacello API? >>>>> >>>>> Thanks >>>>> T. >>>>> >>>>> [1] >>>>> https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… >>>>> >>>>> >>>> >>>> >> > > >

Sept. 22, 2016

Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

by Max Leske

Hi Eliot, > On 22 Sep 2016, at 20:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Thu, Sep 22, 2016 at 11:42 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > >> On 22 Sep 2016, at 20:28, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Bert, Hi All, >> >> On Thu, Sep 15, 2016 at 2:55 PM, <commits(a)source.squeak.org <mailto:commits@source.squeak.org>> wrote: >> [snip] >> http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.… <http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.…> >> >> Name: System-bf.916 >> Ancestors: System-bf.915 >> >> Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects. >> >> Also removes support for writing segments. >> >> This overrides the Spur support introduced in System-eem.758. >> >> So one question is should we delete VM support for ImageSegment from the Spur VM? There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code. That's a lot, and the code is complex and ugly. If it never really worked before IMO we should nuke it asap. If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM. >> >> What do others think? > > As long as you donât remove it from the Cog VMâs until I no longer need it Iâm fine with that. > > And when would that be? Canât really say but I'm hoping to get rid of ImageSegment within the next 2 years (very rough estimate). > Do you mean that you use it in ways not covered by Bert's modifications (which render the VM support superfluous), or do you mean that you use ImageSegment as a naive consumer and are happy just so long as it works? Speed is important to me, as I use ImageSegment to create snapshots of our applications (and hence I need write support, which Bert apparently removed). Those snapshots can exceed 90 MB and the graphs include thousands of objects. I fear that a pure Smalltalk implementation would not be fast enough. On the other hand, we would simply not move to a VM version without ImageSegment support, so that case may give me the boost I need to get rid of ImageSegment :) Currently weâre preparing to move to our first Cog VM in production. If you can give me 2 or 3 months, so that I know the version we use works for us, you could then remove ImageSegment support and we would start replacing ImageSegment with something else so we could keep updating our VM. Cheers, Max > > > Max > >> >> _,,,^..^,,,_ >> best, Eliot > > > > > > -- > _,,,^..^,,,_ > best, Eliot

Sept. 22, 2016