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

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

by Henrik-Nergaard

Here is a fix. ------------------------------------ PositionableStream>>#upToAll: aCollection "Answer a subcollection from the current access position to the occurrence (if any, but not inclusive) of aCollection. If aCollection is not in the stream, answer the entire rest of the stream." | output pattern | aCollection ifEmpty: [ ^ collection species empty ]. output := (collection species new: 100) writeStream. pattern := aCollection readStream. [ pattern atEnd ] whileFalse: [ | item | self atEnd ifTrue: [ output next: pattern position putAll: aCollection startingAt: 1. ^ output contents ]. item := self next. (pattern peekFor: item) ifFalse: [ output next: pattern position putAll: aCollection startingAt: 1; nextPut: item. pattern reset. ]. ]. ^ output contents ------------------------------------ Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 30, 2017

Replacement for deprected MultiByteFileStream?

by Bernhard Pieber

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

nice list :) > On 30 Dec 2017, at 13:13, Norbert Hartl <norbert(a)2denker.de> wrote: > > My list would be in order of importance: > > - stable 64bit vm > - mature iceberg plus dependent tools > - no endless loop in debugging anymore aka real stoppable computation > - bootstrap aka small image > - vm with collaboration support > - working SSL on newer distributions > - unified keymapping > - improved epicea > - better parser support aka core petit parser in the image > - basic document model in the image for documentation aka mini pillar > - bloc plus basic widgets > - better modification tracking support > - runtime traits / dynamic layers > - better set of slot classes for types and relations > > Norbert > >> Am 23.12.2017 um 17:58 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> 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 > -------------------------------------------- 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] Streaming over a UTF-8 encoded file using upToAll:

by Bernhard Pieber

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] Streaming over a UTF-8 encoded file using upToAll:

by Bernhard Pieber

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

Pharo 7 crash on Mac

by Bernhard Pieber

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] Simple game framework

by Dimitris Chloupis

Problem is that people , coders and users, tend to underestimate the complexity of game development. 99% of the technology we use nowadays is game based. Powerful GPUs utilized by consumer computers and supercomputer alike to deal with highly complex problems like cancer research and simulations of the Bing Bang. Massive memory that is millions time large than technology that existed 30 years ago. A computer with 128GB of memory is exactly 1 million times bigger than my first computer with 128 kbs of memory that will become 30 years old in exactly one year. Massive super fast hard drives. Multi core CPUs The internet. Anything you look around you has so massively progressed , only because of high end games that have created the most profitable business for half a century. No other kind of software comes remotely close to pushing the hardware to such extremes and yet being so massively popular as high end games. So game APIs are extremely complex even for the simplest games. In Python for example we have , or rather had , Pygame , itâs as massively popular with beginners game developers as its massively unpopular with profession or very experienced amateur game developers. The latest Pygame is basically SDL with some extra game stuff. Why people donât use it beyond proof of concept ? One word âSimpleâ What the rest of the computer world pursue as the holy grail in game development is nothing more than a bad allergy . Why ? Because You will be far better in embracing the extremely complex engines on the market even for the creation of the simplest games. The moment you decide that using such an engine is an overkill for your so simple needs and that you donât have to endure their very steep learning curve is the moment you condemn yourself to a full rewrite if there is a remote chance of taking the game one step further. We all know how much fun full rewrites are. In short making games is no game. Go use a professional engine and you can thank me later. On Thu, 28 Dec 2017 at 19:53, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > On Thu, Dec 28, 2017 at 4:39 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > >> What is the reason using Cairo over SDSL? Is not SDL just enought? > > > My understanding is that SDL provides the surface to draw on as part of > the window, but not a 2D vector graphic engine on top. You've got only draw > Line/Rect/pixel functions in SDL. To render a svg/png/jpeg that you want > for games on the SDL surface, the normal way is to use a third party > library such as Cairo. > > For 3D I believe people use SDL combined with open GL or direct3D instead > of Cairo but I don't know the details. > > For events (keyboard, mouse, joypad) I use SDL event management and it > works differently on each OS. I wrote in the readMe the different set-ups > to make it work on each OS. On Windows and Linux I can use the latest > Pharo. On Mac I use old Pharo 5 images. > > I guess it's possible to use SDL for audio, but it seems there is no code > relative to audio in the SDL binding and in OSWindow in Pharo. That's why I > did not go that way. I tried multiple things but I successfully run audio > code in Pharo only with the openAL binding and .wav file (and even in this > case, I had to install external librairies in Mac OS...). > > Whichever if Cairo stays around or not does not really matter, normally > one uses Cairo through Athens or Sparta, abstraction layers on top of 2D > graphic engines. I've worked with other 2D engines and the API are always > almost the same, so I have no doubt that if Cairo support is dropped we can > re-bind Athens/Sparta with another 2D engine (such as engines used by web > browsers). > > >> >> Hilaire >> >> >> Le 25/12/2017 Ã 19:32, ClÃ©ment Bera a Ã©crit : >> >>> >>> https://github.com/clementbera/wizard-battle-arena >>> >>> https://github.com/clementbera/SpiderInvasion >>> >>> Audio has always been a problem to me. I successfully run audio files >>> with the open AL binding, but I failed to do so cross-platform. Already >>> key-bindings coherent cross platform is difficult. >>> >>> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >> > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve > d > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > 'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >

Dec. 30, 2017

Re: [Pharo-dev] Best wishes for 2018

by Dimitris Chloupis

Canât imagine myself ever coming remotely close to hating you. Big thanks to you and the rest of the community for keeping the dream alive and kicking. Looking back to 2011 when I first joined, Pharo has come a long way and nowadays it looks and is comparable to other far more popular languages and the fact our community is small is the ultimate proof of its high productivity. What makes me most happy with Pharo is that it has retained all the important parts of Smalltalk and also, even though I never did and never will hesitate for a second to compare Pharo to other languages and break the misconceptions - prejudice against them, Pharo for me has become a breath of fresh air, not afraid to follow its own path but at the same time not afraid of embracing the practical needs of coders struggling with finding bugs and retaining this direct connection with the machine instead of being lost inside its own massive complexity. Pharo has built a very solid yet flexible foundation that stands as the torch that keeps the flame alive and making Smalltalk more relevant to modern coders than ever before. Itâs living proof that Smalltalk is not a relic of the past,an outdated philosophy, great in theory , bad in practice but a life form that is made of binary code like anything else but on the same time far more capable of surviving, adjusting , evolving and thriving in a world that accelerates to light speed in matters of technology and science even though the world still struggles with basic concepts. Like a real transformer , Pharo is technology from the future and there is definetly more than meets the eye. I wish health and happiness to all and as always Keep dreaming with open mind On Fri, 29 Dec 2017 at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Thanks Torsten, > I was about to write a similar mail. > > Thanks to everybody for allow me to be your âguy to hateâ :) > I will continue doing my best to make Pharo a better place for everybody, > one step at a time. > > happy new year! > Esteban > > > On 29 Dec 2017, at 09:39, 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] PharoSpur32Vm

by Nicolai Hess

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@ > 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/bi >>>> n:/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/opens >>>> malltalk-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/opensm >>>> alltalk-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\Loa >>>> dVMMaker.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 Bernhard Pieber

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. 29, 2017