- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PR: Compressed sources inside the object memory

by Stephane Ducasse

Not Pharo 70. Too many issues on other fronts. Ring2, calypso, iceberg.... On Thu, Dec 28, 2017 at 5:05 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-12-28 16:21 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >> >> >> 2017-12-28 16:00 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>> Nice. >>> >>> 2017-12-28 15:50 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>> >>>> 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 >>> >>> >>> And how many objects it adds? (how many sections are compressed?) >> >> >> It uses currently 1619 segments of size 20000 bytes but that does not mean >> that such amount of objects is needed because in the memory filesystem all >> the (compressed) data are in single ByteArray and the stream class uses a >> very simple segments table - one big array of 1619 integer items that >> contain indexes to the ByteArray. >> >>> >>>> >>>> - 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 >>> >>> >>> Can we avoid empty changes file? We can create it on demand (when user >>> modifies code for example). >> >> >> I think we can because it contains only do-its. We should be able to >> simply delete it and only modify the image start-up do do not require it. > > > It is unbelievable that we can have single image file. I think it is very > attractive goal for Pharo 7. And it is so close. > >> >> >> -- Pavel >> >>> >>> >>>> >>>> >>>> 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%2… >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>> >>> >> >

Dec. 30, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Sven Van Caekenberghe

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… 1.4. Converting Streams > On 30 Dec 2017, at 13:27, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > 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

Dec. 30, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Stephane Ducasse

Thanks for asking because I hope that this is the case. Stef On Sat, Dec 30, 2017 at 2:59 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2017-07-23 23:18 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> >> >> 2017-07-23 22:38 GMT+02:00 Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>> >>> >>> 2017-07-23 19:56 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>> >>>> >>>> 2017-07-23 19:42 GMT+02:00 HernÃ¡n Morales Durand >>>> <hernan.morales(a)gmail.com>: >>>>> >>>>> 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, >>>> >>>> >>>> I always had problems using mingw in the past. I got a working mingw >>>> environment some years ago, and a newer mingw version >>>> did not work well (some changes on the debug and exception format). >>>> But now, the build process for pharo did change. (The build instructions >>>> on github/pharo-vm are old and do not work anymore. >>>> >>>> And I hoped to get a more automatic and more reliable build process by >>>> using the same commands used by the build server for >>>> the opensmalltalk pharo vm sources. >>>> >>>> And I thought the compiler used to build the latest pharo-vm for windows >>>> is from cygwin ? >>>> >>>> >>> >>> Hi Nicolai, >>> more exactly we cross compile from a cygwin environment for a mingw >>> target. >>> The main reason for switching to cygwin are: >>> - this is required for the 64 bit vm >>> - the other flavours on opensmallalk (squeak/newspeak) were also built >>> with cygwin, so it's more simple to maintain a single way of doing things >>> >>> Cygwin is required for the 64bits vm because of directx. >>> Indeed cygwin still provides support for the legacy directx version used >>> by the VM, while recent mingw does not. >>> Until we port to a newer API, mingw thus depends on the MS directx >>> include and library files that we redistribute for 32 bits only (and we >>> should not without permission, I plan to remove these files). That does not >>> work at all for 64 bits. >>> >>> The 64bits VM does not work either with gcc and requires clang currently. >>> installing clang in mingw is tedious, while it's a prebuilt package in >>> cygwin. >>> >>> You now know why we use cygwin, not how, maybe it does not terribly >>> helps, but it's important in order to avoid regression, or to be aware of >>> what need to be done before changing the building environment again... >>> Could you detail what you tried exactly? >> >> >> >> Setup cygwin: >> >> CYG_MIRROR=http://cygwin.mirror.constant.com >> CYG_ROOT='c:\cygwin' >> CYG_SETUP=setup-x86.exe >> MINGW_ARCH=i686 >> $CYG_SETUP -dgnqNO -R $CYG_ROOT -s "$CYG_MIRROR" -l >> "$CYG_ROOT"/var/cache/setup -P >> mingw64-$MINGW_ARCH-gcc-core,mingw64-$MINGW_ARCH-gcc-g++,mingw64-$MINGW_ARCH-headers,mingw64-$MINGW_ARCH-runtime,zip,mingw64-$MINGW_ARCH-clang,libiconv-devel,libglib2.0-devel,perl,mingw64-$MINGW_ARCH-zlib,cmake,mingw64-$MINGW_ARCH-win-iconv,make,wget >> >> (taken from the appveyor.xml, I needed to add make and wget, don't know >> why, from the appveyor log I see that make and wget is installed, even >> without this option...) >> >> Run the build (from an "empty" environment, that is, no other msys or >> mingw in the path environment variable) >> >> set FLAVOR=pharo.cog.spur >> set ARCH=win32x86 >> set MINGW_ARCH=i686 >> set CYG_ROOT=c:\cygwin >> set TRAVIS_OS_NAME=windows >> set PATH=%CYG_ROOT%\bin;p:\git\bin;%PATH%; >> git config --system core.autocrlf input >> git clone -q --depth=5 --branch=Cog >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git C:\projects\vm >> SET APPVEYOR_BUILD_FOLDER=c:\projects\vm >> git checkout -qf 88c4c56245f3308e711b38467bb7636864886d16 >> %CYG_ROOT%\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER;exec 0</dev/null;exec >> ./.travis_build.sh" >> > > I still have problems building the pharo vm locally with the above setup. > Somehow I can not build the thirdparty libs > The compiler I use from the cygwin installation is > i686-w64-mingw32-gcc > But I can not see where this is set for the third party libs (starting with > pkg-config). > > Are they really build on the travis build server ? I can not see it in the > build log. > > nicolai > > > >> >> >> >>> >>> >>> Nicolas >>> >>>>> >>>>> 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 >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>> >>>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>> >>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>>> >> >>>>> > >>>>> >>>> >>> >> >

Dec. 30, 2017

Re: [Pharo-dev] Streaming over a UTF-8 encoded file using upToAll:

by Stephane Ducasse

Thanks. What I understood is that positionableReadStream does not work with variable elements like utf-8 because there is no 1 to 1 mapping. On Sat, Dec 30, 2017 at 12:54 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > I created an issue for this: > https://pharo.fogbugz.com/f/cases/20898 > > Bernhard > >> Am 30.12.2017 um 12:01 schrieb Bernhard Pieber <bernhard(a)pieber.com>: >> >> I just checked and the bug in #upToAll: is still there in Pharo 7. >> >> Bernhard >> >>> Am 29.12.2017 um 20:26 schrieb Bernhard Pieber <bernhard(a)pieber.com>: >>> >>> Hi Henrik, >>> >>> Thanks for your answer. Sounds like a bug, then. :-/ >>> >>> Cheers, >>> Bernhard >>> >>>> Am 28.12.2017 um 20:31 schrieb Henrik-Nergaard <draagren(a)outlook.com>: >>>> >>>> Hi, >>>> >>>> #upTo: works fine. >>>> >>>> 'test' asFileReference readStreamDo: [ :stream | stream converter: >>>> UTF8TextConverter new; upTo: $e ]. "'Ã'" >>>> >>>> It looks like PositionableStream>>#upToAll: assumes a 1 to 1 map per item, >>>> and only takes the difference between current position up to the pattern >>>> when found. >>>> >>>> Best regards, >>>> Henrik >> > >

Dec. 30, 2017

Re: [Pharo-dev] Pharo 7 crash on Mac

by Stephane Ducasse

Hi bernhard I can crash pharo 60 and 70 on sierra nearly 3 times per 30 min. Because of a bad key combination. So I save often and do not use the arrow keys. :( We will have to address this super super super annoying problem. Now may be this is not the same bug. Guille is currently refactoring, adding many tests to Iceberg internal representation. Stef On Sat, Dec 30, 2017 at 11:03 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > 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 >

Dec. 30, 2017

Re: [Pharo-dev] Best wishes for 2018

by Stephane Ducasse

Tx. Nice picture! On Fri, Dec 29, 2017 at 9:39 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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. >

Dec. 30, 2017

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Stephane Ducasse

Hi Bernhard Have a look at how guille started to implement File package. (Guille is actively converting all the image users of the old hierarchy but last time he losts a couple of hours because changing epicea and other users of positionable streams and sourceArray... at the same time was leading to complex situations :). But Guille told me that he learned and will come back to this.) He is using ZnCharacterWriteStream and wrapper like ZnCrPortableWriteStream. writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag | extension fileName outputStream | extension := stOrCsFlag ifTrue: ['.st'] ifFalse: ['.cs']. fileName := baseName, extension. fileName := FileSystem disk checkName: fileName fixErrors: true. outputStream := (File named: fileName) writeStream. (ZnCrPortableWriteStream on: (ZnCharacterWriteStream on: outputStream encoding: 'utf8')) nextPutAll: aStream contents. outputStream close. writeSourceCodeFrom: aStream toFileReference: aFileReference aFileReference writeStreamDo: [ :outputStream | (ZnCrPortableWriteStream on: (ZnCharacterWriteStream on: outputStream encoding: 'utf8')) nextPutAll: aStream contents. ]. self inform: 'Filed out to: ', String cr, aFileReference basename self inform: 'Filed out to: ', String cr, fileName. I hope it helps. Stef On Sat, Dec 30, 2017 at 1:27 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > 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

Dec. 30, 2017

Re: [Pharo-dev] New Year Wishlist (2018) ?

by StÃ©phane Ducasse

Me too :) > On 30 Dec 2017, at 15:51, Holger Freyther <holger(a)freyther.de> wrote: > > >> On 30. Dec 2017, at 20:13, Norbert Hartl <norbert(a)2denker.de> wrote: > > Hey! > > >> - working SSL on newer distributions > > related to that I would love a working VM release process. > > - Tag releases of the stable VM > - Be able to take release X.Y and release X.Y+1 with a single bugfix -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Dec. 30, 2017

Re: [Pharo-dev] New Year Wishlist (2018) ?

by Holger Freyther

> On 30. Dec 2017, at 20:13, Norbert Hartl <norbert(a)2denker.de> wrote: Hey! > - working SSL on newer distributions related to that I would love a working VM release process. - Tag releases of the stable VM - Be able to take release X.Y and release X.Y+1 with a single bugfix

Dec. 30, 2017

Best VM for the Mac>

by Sean P. DeNigris

What is the best VM right now for the Mac? Where/how would one get it? I recently downloaded a fresh Launcher from CI which comes with CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017, but get.pharo.../vm70 downloads CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017â¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 30, 2017