December 2017 - Pharo-dev - lists.pharo.org

How to restore image upgrade? was New Year Wishlist (2018) ?
by Nicolas Cellier Jan. 4, 2018

Jan. 4, 2018

2017-12-24 2:59 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > My four wishes, in no particular order: > - Better code completion > - Git in Pharo as easy as using Git for other languages > The recipe is easy: turn pharo into a file based edit-compile-run language and expunge those live object burden ;) Let me explain why it's not just trolling. Currently we have to download an image made by a bot. Pharo has gradually lost the power to upgrade the image (it's not new). If we recognize that an image acts like a workspace, and want to let the pull/branch switch/etc work again... IOW going from one point to any other in source code graph and experience the full power of git like any other language, that means, in a live IDE, at least solving those two problems: - changing the tools that are used to upgrade the image (Compiler, MethodDictionary, Array, etc...) - correctly initialize all the states (including stange loops) If pharo has not managed to solve this with a linear one way history (the regularly broken update image option), how do you think this is going to be solved in the more general case? I call this the universal boostrap problem. IMO the logical next step is to separate the IDE (the Inanimate Desintegrated Environment of any other language). Maybe we don't have to bend Pharo too much to git if it does not fit. The goal: as easy might be not that easy. - Bloc on Steroid > - Being able to interrupt any process and endless loop using Cmd-. > > Merry Christmas to all of you! > Alexandre > > > > > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > Hi everybody, > > > > This looks like a good moment of the year to ask all of you what would > you want to see in Pharo next year. > > Features, improvements, radical changes, etcâ¦. whatever you want. > > > > Of course, this list will not be a roadmap and it does not means we will > implement all of it (as always, time drives our possibilities), but is a > good moment for us a a community to check where we are and where we wan to > go next :) > > > > So, letâs those wishes come! > > > > cheers, > > Esteban > > >

4 5

Replacement for deprected MultiByteFileStream?
by Bernhard Pieber Jan. 4, 2018

Jan. 4, 2018

I just saw that the FileStream hierarchy including MultiByteFileStream is deprecated. However, I can't find what file stream class should be used to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also uses MultiByteFileStream. Can someone please point me to the right code? Bernhard

7 15

Pharo 7 crash on Mac
by Bernhard Pieber Jan. 2, 2018

Jan. 2, 2018

Hi, I wanted to set up a new Pharo 7 image for contributing. I used the description from here: https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo After I had successfully cloned the pharo repository Pharo crashed. I am afraid I cannot remember the last thing I did before the crash. Nevertheless, maybe the crash dump is of some use for someone being able to interpret its content. I am on macOS Sierra 10.12.6. ./pharo --version 5.0 5.0.201708271955 Mac OS X built on Aug 27 2017 20:27:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53) [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Happy New Year! Bernhard

4 6

Best wishes for 2018
by Torsten Bergmann Jan. 1, 2018

Jan. 1, 2018

Only a few days left for 2017. Thanks to all who helped shaping Pharos future. May the lighthouse be with you in 2018 as well: World backgroundImage: (ZnEasy getJpeg: 'https://spotlight.it-notes.ru/wp-content/uploads/2017/08/02c48424be88ee36d5…') layout: #scaled Have fun! Bye T.

9 12

Streaming over a UTF-8 encoded file using upToAll:
by Bernhard Pieber Dec. 31, 2017

Dec. 31, 2017

Hi all, I want to stream over a file which is encoded in UTF-8 and have a problem with upToAll: answering more than it should. Here is a minimal test: 'Ãe' readStream upToAll: 'e'. This answers 'Ã' as expected. I wrote those two characters to a file: FileStream forceNewFileNamed: 'test' do: [ :stream | stream nextPutAll: 'Ãe' ]. I opened it using a text editor to verify the encoding. It is UTF-8 as expected. Now if I do the following... 'test' asFileReference readStreamDo: [ :stream | stream upToAll: 'e' ]. ... I get 'Ãe' instead of just 'Ã'. I tried explicitly setting a UTF8TextConverter: 'test' asFileReference readStreamDo: [ :stream | stream converter: UTF8TextConverter new; upToAll: 'e' ]. However, the result is still 'Ãe'. If I read the entire file first using #contentsOfEntireFile first it works: ('test' asFileReference readStreamDo: [ :stream | stream contentsOfEntireFile ]) readStream upToAll: 'e' However, that defies the purpose of streaming. Can someone tell me what I am doing wrong? I am on Pharo 6.1 on a Mac. Bernhard

3 8

FreeCell resurrection
by Pavel Krivanek Dec. 31, 2017

Dec. 31, 2017

Hi, I fixed the old FreeCell code from Squeak to be able to run on Pharo 6 and 7. Repository: https://github.com/pavel-krivanek/FreeCell How to load: Metacello new baseline: 'FreeCell'; repository: 'github://pavel-krivanek/FreeCell/src'; load. How to run: FreeCell open. Cheers, -- Pavel

1 0

an error in ZnResourceMetaUtils>>queryKeyValueSafeSet ?
by Esteban Lorenzano Dec. 31, 2017

Dec. 31, 2017

Hi all, Sven Iâm doing some experiments with twitter and posting and I found that twitter does not accept a post with $? in the status string (it throws an error). Now, if I change ZnResourceMetaUtils>>queryKeyValueSafeSet removing $? from the safe set it works correctly. the question is: this is a twitter error or a ZnResourceMetaUtils>>queryKeyValueSafeSet error and the $? shouldnât be considered safe (and then it should be percent encoded?) cheers, Esteban

2 3

Calendrical capabilities
by publius789＠gmail.com Dec. 30, 2017

Dec. 30, 2017

I am new to the Pharo world and looking at capabilities for potential applications. One of the first things I am interested in is Calendar processing capabilities. I haven't had a chance to look at the code yet, but specifically how much does Pharo's Date/Calendar capabilities match that in the java.util package for Java 9? Additionally, is there any way to give the number of business days between two dates for a particular local calendar? If so, what's the format for a local calendar? I'm going to take a look at the code shortly, but if anyone can shed a general light what currently exists it would be greatly appreciated. Regards, Jim

4 7

PR: Compressed sources inside the object memory
by Pavel Krivanek Dec. 30, 2017

Dec. 30, 2017

Hi, when the Pharo 7 image is being built on top of the bootstrapped image, all loaded code is placed in the changes file so this process ends with an empty sources file, huge changes file and the image. We condense the sources file for every build so we distribute the Pharo 7 as three files - image, huge sources (over 30 MB) and almost empty changes file. As consequence every build has own sources file that can be shared between images based on the same build - so when we will release the Pharo 7, the sources file can be shared as it was for previous releases, but as soon as some fixing version of Pharo 7 will be released, it will require a new specific sources file. As one possible solution I tried to create a pull request that resurrects from oblivion an old code made for Squeak 3.7 that introduced option of compressed sources files. Such files use segments that are stored in compressed form so it is not so small as one single zip file but still good enough. From original uncompressed file of size 30.8 MB it generates 7.1 MB file while single zip has 6.1 MB. Of course the image file is bigger but: - the amount of new objects is low so it should not make much more stress on GC - we already used to have big images because the condenser was not working and it was not a big issue - the amount of distributed files will be the same as in case of Pharo 6 (image+changes) so it means less troubles - the sources file can be easily restored, deleted from the object memory and used the same way as before - we are not using the nice concept of the image well enough. All data that are not really shared between images or serve as backup information should be stored inside image Please review this PR. As a side effect it makes the sources file mechanism (but not changes file) independent on the FileStream classes that are deprecated. PR: https://github.com/pharo-project/pharo/pull/631 The pre-built image: https://ci.inria.fr/pharo-ci -jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-631/ lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip Cheers, -- Pavel

4 13

Re: [Pharo-dev] PharoSpur32Vm
by HernÃ¡n Morales Durand Dec. 30, 2017

Dec. 30, 2017

2017-07-22 10:03 GMT-03:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > Hm, I tried to create the build environment used for the > windows vm build from opensmalltalk. > > I setup a cygwin environment with the same install commands as from > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml > > My problems, first it is missing make and wget, I can add make and wget to the install command line for cygwin, but I am > curious why it is working on the build server ? > > Anyway, after I got this working, the build stops and building the pkg-config package. > The log says it can not find a gcc, I know that the build process with cygwin uses > i686-w64-mingw32-gcc > or > x86_64-w64-mingw32-gcc > > But I don't understand where is the missing step to tell the configure scripts to use the > > i686-w64-mingw32-gcc command instead of "gcc", > > again, this seems to work on the appveyor build but not locally on my machine. > > Any idea what I had missed? > I solved it in MinGW by adding the path of i686-w64-mingw32-gcc.exe in your profile. So if you profile is c:\MinGW\msys\1.0\etc\profile and the .exe is in /c/MinGW/msys/1.0/bin then change as administrator the line: MSYS2_PATH="/usr/local/bin:/usr/bin:/bin" to MSYS2_PATH="/c/MinGW/msys/1.0/bin:/c/MinGW/bin:/usr/local/bin:/usr/bin:/bin" And finally source /etc/profile Cheers, HernÃ¡n > > nicolai > > > > 2017-03-15 10:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> >> >> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be <philippe.back(a)gmail.com>: >>> >>> I made my own build here. >>> Not up to date with latest stuff but should work for the build process. >>> >>> https://ci.appveyor.com/project/philippeback/pharo-vm >>> >>> It uses my forked repo and provided you set your own bintray env vars for API keys will publish there. >>> >>> Check all of the output of env vars and where/which in the appveyor console to see what gets used when when it comes to compilers and so on as there were various compiler versions involved at one point. >>> >>> Third party cache part is also worth checking. >>> >>> Still not able to build on my local box at the moment due to some tools discrepancies happening. >>> >>> My build artifacts are embarking too much at this point but allow you ro get the release, debug, and assert vms for windows. This helps when debugging as backtraces and so on are much more meaningful and one can use gdb more effectively to understand what is going on. >>> >>> Just keep the dlls and exes and you'll be fine. >> >> >> Ah good, thank you. >> >> >>> >>> >>> HTH >>> >>> Phil >>> >>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : >>>> >>>> >>>> >>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> >>>>> >>>>> >>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>>>>> >>>>>>>> Hi Nicolai, >>>>>>>> >>>>>>>> If you look at appveyor.yml configuration on https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, you will see that the pharo brand is not yet in the matrix. >>>>>>>> >>>>>>>> It's because builds are based on cygwin, but as I understood, some library used by some plugin required by pharo refuse to compile with cygwin. They appear to work with mingw32. >>>>>>>> Cygwin provides headers for legacy directx, some distribution of mingw32 did in the past, but it does not seem the case anymore. >>>>>>>> Using the directx headers from Microsoft SDK is a problem. They are not redistributable and can't be found anymore on the net (too old). We cannot seriously base the builds on something so fragile (both technically and legally) in the long term. >>>>>>>> >>>>>>>> Also, the 64 bits VM does only work with clang, and we don't have anything available as a 64bits Microsoft SDK... So pharo has to fix that too. >>>>>>>> >>>>>>>> In the interim, you should look at https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml and follow the scripts there. >>>>>>> >>>>>>> >>>>>>> Ok, thank you. >>>>>>> >>>>>> >>>>>> >>>>>> I gave it a shot on sunday, because it was particularly rainy in Nantes, and I almost succeeded in compiling all the dependencies with cygwin. >>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely forget a few other niceties that some not so well informed programmers committed with the faith that it would make their life "easier". It certainly does not make mine simpler... >>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it seems that the workaround of Igor does not work anymore. >>>>>> ssize_t, WTF??? >>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll publish the branch to see how far appveyor goes. >>>>>> >>>>>> >>>>> >>>>> >>>>> So I solved the ssize_t problem by removing the hack from Igor which is not necessary anymore... >>>>> But got another problem soon after while building the tests... >>>>> There are trailing lines generated at end of tests/cairo-test-constructors.c that make the compilation fail: >>>>> >>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 -Wno-unused-but-set-variable -D_REENTRANT -m32 -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c -o cairo_test_suite-cairo-test-constructors.o `test -f 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de donnÃ©es n'a pas de type ni de classe de stockage >>>>> oning (); >>>>> ^ >>>>> cairo-test-constructors.c:1118:1: attention : type defaults to âintâ in declaration of âoningâ [-Wimplicit-int] >>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de donnÃ©es n'a pas de type ni de classe de stockage >>>>> _register_ft_show_glyphs_table (); >>>>> ^ >>>>> >>>>> And the file looks like it has obviously been overwritten, but not truncated !!! >>>>> >>>>> ... >>>>> extern void _register_multi_page (void); >>>>> extern void _register_fallback_resolution (void); >>>>> >>>>> void >>>>> _cairo_test_runner_register_tests (void) >>>>> { >>>>> _register_a1_bug (); >>>>> _register_a1_clip_paint (); >>>>> ... >>>>> _register_multi_page (); >>>>> _register_fallback_resolution (); >>>>> } >>>>> oning (); >>>>> _register_ft_show_glyphs_table (); >>>>> _register_ft_text_vertical_layout_type1 (); >>>>> _register_ft_text_vertical_layout_type3 (); >>>>> _register_ft_text_antialias_none (); >>>>> _register_ps_eps (); >>>>> _register_ps_features (); >>>>> _register_ps_surface_source (); >>>>> _register_svg_surface (); >>>>> _register_svg_clip (); >>>>> _register_svg_surface_source (); >>>>> _register_multi_page (); >>>>> _register_fallback_resolution (); >>>>> } >>>>> >>>>> This file is generated by a shell script test/make-cairo-test-constructors.sh >>>>> I can't find any reference of the bug, and upgrade to version 1.14.8 does not solve the issue. >>>>> So it will wait until tomorrow... >>>> >>>> >>>> >>>> I got the build for windows with mingw nearly working. (it can not build some plugins, like SqueakSSL for windows, because the used wincrypt.h is different in the mingw distrubtion). >>>> >>>> I still have the problem, that there seems to be a preprocessing step , that should put the vm-version (and source timestamp) in the sqSCCSVersion.h >>>> I got this working by running .travis_build.sh (with the options for arch/flavor/platform) But how is this done normally when you build a vm locally? >>>> And how is this done for the pharo-vm we currently use? >>>> >>>> >>>>> >>>>> >>>>> Nicolas >>>>> >>>>>>>> >>>>>>>> I hope that Esteban will find time to resolve all these problems and have pharo brand back on opensmalltalk-vm. I guess that any form of help is welcome. >>>>>>>> >>>>>>>> Nicolas >>>>>>>> >>>>>>>> >>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>> >>>>>>>>> I still have problems building a vm on windows. >>>>>>>>> can you give me some hints how to start ? >>>>>>>>> I cloned the recent pharo-vm project, >>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>>>>>> run >>>>>>>>> mvm >>>>>>>>> >>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not found, I had to adjust the include path for finding directx header, missing variable replacement for git-versions). >>>>>>>>> So I may miss some important steps. >>>>>>>>> Is there a repository where I can clone the mingw environment used to build the win32-pharo-vm, the environment used on the build-server ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Nicolai >>>>>>>>> >>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I believe they're built from https://github.com/OpenSmalltalk/vm using travis and appveyor. On the gitbhub readme there are relevant links. All built artifacts are also kept on bintray for history. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> no, they arenât :) >>>>>>>>>>>> instead, they are built here: https://github.com/pharo-project/pharo-vm >>>>>>>>>>>> >>>>>>>>>>>> (README still not updated) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> what did changed ? I am not able to build the vm on windows anymore (something wrong with generating the generator.image, I'll now reset my local pharo-vm build directory and see if it works afterwards). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> see attached the stderr log : >>>>>>>>>> >>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st' >>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>>>>>>> BaseSoundSystem class>>initialize >>>>>>>>>> MCMethodDefinition>>postloadOver: >>>>>>>>>> >>>>>>>>>> .... >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Are we still working with branch spur-64, or are we back on master ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Esteban >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>>>>>>>>>>>>> I don't see them on the build server, only the buildresults at >>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> The latest builds on the buildserver are from the last year only. >>>>>>>>>>>>>> >>>>>>>>>>>>>> nicolai >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >

4 5