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

Re: [Pharo-dev] Best VM for the Mac>

by Sean P. DeNigris

Sean P. DeNigris wrote > What is the best VM right now for the Mac? Where/how would one get it? Bump ;) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 31, 2017

Re: [Pharo-dev] an error in ZnResourceMetaUtils>>queryKeyValueSafeSet ?

by Esteban Lorenzano

now I found that also $@ and $! are problematic for twitter api. soâ¦ Iâm guessing is a problem of twitter more than a generic error (this would have been spotted before, if is a bug). I need to dig to see if I can explicit an encoding in some way instead hacking over #queryKeyValueSafeSet (but that will be hard to do today ;) ) Esteban > On 29 Dec 2017, at 10:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi Sven, > > A POST with this form will fail on twitter api: > > POST /1.1/statuses/update.json HTTP/1.1 > Host: api.twitter.com > Content-Type: application/x-www-form-urlencoded > Accept: */* > Content-Length: 0 > User-Agent: Zinc HTTP Components 1.0 (Pharo/7.0) > > status=testing? > > It will fail because of the â?â, if I remove ? from save and I encode as this: > > POST /1.1/statuses/update.json HTTP/1.1 > Host: api.twitter.com > Content-Type: application/x-www-form-urlencoded > Accept: */* > Content-Length: 0 > User-Agent: Zinc HTTP Components 1.0 (Pharo/7.0) > > status=testing%3F > > it will be posted correctly. > > My doubt if this is a bug in queryKeyValueSafeSet or this is a particular problem on twitter. If the last, I didnât see a good way to change value of safe set for just one case (for now I just override the method, but this is clearly not good ;) ). > > cheers! > Esteban > > >> On 28 Dec 2017, at 13:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi Esteban, >> >>> On 28 Dec 2017, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> 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 >> >> I know that the last time I did the implementation, we looked very carefully in what characters are safe or not, and had some discussions about it. >> >> I am not familiar with the API you are trying to use. I am a bit confused by POST and 'status string', while encoding a query part of the URL. It is possible to show exactly the call that you are trying to make ? What does an equivalent curl -v call show ? Could you point to the actual API call documentation ? >> >> Sven >> >> >

Dec. 31, 2017

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

by Stephane Ducasse

Which reminds me that we should publish these HTML in another location.... Just too many things to do :( But at least we get pdf and HTML and more if needed for our books. On Sat, Dec 30, 2017 at 6:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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] Simple game framework

by Stephane Ducasse

Hilaire why do you need to have a sprite on a SDL surface and why plain Athens is not good enough. Athens is an API not an implementation. It is like sparta: an API and you do not care about the library below. OSWindow is a layer on top of SDL and it is better than SDL directly to my understanding. So you should get Athens and SDL for event. What kind of game are you targeting? Did you look at Bloc? Because to me this is the way to go except if you want just a canvas and reimplement your event loop. in that case SDL + Athens should work. Stef On Sat, Dec 30, 2017 at 9:33 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > I found the mix of OSWindow+SDL+Athens very complex (tens of classes with > hundreds of methods) and to produce code hard to understand (I look at your > spider code). > > I will prefer fewer functionnality I can understand. > > For example, how can you copy a sprite on a SDL surface? Can you do it > without Athens surface? > > > Le 28/12/2017 Ã 18:51, ClÃ©ment Bera a Ã©crit : >> >> 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). > > > -- > Dr. Geo > http://drgeo.eu > > >

Dec. 30, 2017

Re: [Pharo-dev] Simple game framework

by Hilaire

I found the mix of OSWindow+SDL+Athens very complex (tens of classes with hundreds of methods) and to produce code hard to understand (I look at your spider code). I will prefer fewer functionnality I can understand. For example, how can you copy a sprite on a SDL surface? Can you do it without Athens surface? Le 28/12/2017 Ã 18:51, ClÃ©ment Bera a Ã©critÂ : > 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). -- Dr. Geo http://drgeo.eu

Dec. 30, 2017

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

by Denis Kudriashov

Thank's Nicolas. It helps 2017-12-30 18:32 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi steph, > There is a workaround > defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool falseâ. > See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 > > Le 30 dÃ©c. 2017 17:58, "Stephane Ducasse" <stepharo.self(a)gmail.com> a > Ã©crit : > >> 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-proje >> ct/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/OpenSmallta >> lk/opensmalltalk-vm.git $ >> > >> > Happy New Year! >> > >> > Bernhard >> > >> >>

Dec. 30, 2017

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

by Nicolas Cellier

Hi steph, There is a workaround defaults write NSGlobalDomain ApplePressAndHoldEnabled -bool falseâ. See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 Le 30 dÃ©c. 2017 17:58, "Stephane Ducasse" <stepharo.self(a)gmail.com> a Ã©crit : > 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] How to restore image upgrade? was New Year Wishlist (2018) ?

by Stephane Ducasse

;) We will get there. I want live update V2.0 for real. On Tue, Dec 26, 2017 at 11:36 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-12-25 23:54 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> As a half-way house, consider that "upgrade" scripts could be a good >> mechanism >> post-Release when changes should be less-deep/less-arduous on the system. >> This might avoid Esteban's time being needed to re-Release for each >> upgrade, >> with post-Release moving to a more community supported mechanism. >> This could scale better as we gain more users interested in long term >> support >> of their applications on a stable-release than the moving target of the >> development-edge. >> >> cheers -ben > > > Hi Ben, > upgrade scripts is what is used by Squeak trunk (as available via > Monticello). > it's difficult to write correctly, and difficult to test (clearly a job for > a bot). > Every intermediate script has to be replayed (or not, but who knows?) and > this is done via MonticelloConfigurationMap. > Can you imagine that transposed to git? > > It's not reversible (we don't provide the reverse scripts). > It might fail due to specific changes in the image (let's say dirty > workspace), and not only code changes. > > So it's very very far from git smoothness. > Fortunately, those scripts are rarely needed (as a percentage of commits). > Unfortunately, they are regularly needed (several times a year). > Remind that Pharo is supposed to change Kernel classes a bit faster than > Squeak ;) > >> >> On 25 December 2017 at 23:11, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Nicolas >>> >>> We want to keep the live part of Pharo and incremental loading and it >>> is key for us. Now we should not be naive. > > > Hi Steph, > Not every provocation deserves an answer ;) > I hope everyone here wants a lively thing, otherwise why use Pharo? > >>> >>> Most of the time we do not have the garantee that a change will work >>> when loaded. >>> > We have bots passing tests for rejecting broken code. > But the problem is that correct code can also be rejected > >>> We proposed Pablo to work since two years on a really working dynamic >>> code loader and >>> Pablo has really nice results. But it takes time to evaluate if/how we >>> integrate its changes. >>> Pablo has an atomic coder loader and an incremental and modular class >>> builder. >>> He also designed a modular shutdown/startup list manager (in production). >>> > Glad to ear that. I hope to read publications on this subject one day then. > Two years for nice intermediate results just confirms that the problem is > very tough as we all know... > >>> We want to be able to have a **real** and robust incremental load. >>> Right now as you know it and as in ANY smalltalk I can break the >>> system super easily. >>> There is no magic. I do not see how we can make sure that any piece of >>> code will be loaded >>> and do not break the system. >>> So our objective is to have a new infrastructure that we can updates >>> (like method hashes for example without having to >>> twists our mind and do five updates). >>> >>> Now about git, we want and we will have our lovely image as a working >>> directory but this requires engineering >>> because the image is another artefact that other languages do not have >>> to worry. >>> We will get there. >>> > > Agree with all you said, > > My point is that git is not going to help you solving the problems others > don't have. > If we have seemless integration for bootstrap free code, that will already > be something... > For the rest, it's a bit too much wishful thinking to my taste. > As said above, because bootstrap problems happen rarely, but regularly, > I can predict that pharo development won't be as smooth as dreamed of for > some time. > We have to accept that and work hard to find acceptable trade offs. > I'm interested in seeing which solution will emerge. > > >>> Stef >>> >>> >>> On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> > >>> > >>> > 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 >>> >> >>> >> >>> > >>> >> >

Dec. 30, 2017

Re: [Pharo-dev] Calendrical capabilities

by Stephane Ducasse

Tx for the links. On Thu, Dec 28, 2017 at 6:00 PM, Michael Forster <mike(a)forsterfamily.ca> wrote: > On Wed, Dec 27, 2017 at 2:38 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Excellent I did not know it. >> >> Stef >> > [...] > > > +1 > > I re-implemented the core Chronos features in PLT-Scheme (Racket) and > Common Lisp years ago. For those interested in Chronos--and to save > them some time digging--here are some links I kept: > > http://chronos-st.blogspot.ca/2006/12/chronos-101-points-in-time.html > http://chronos-st.blogspot.ca/2007/01/chronos-101-durational-values.html > http://chronos-st.blogspot.ca/2007/01/chronos-101-intervals-of-time.html > > > Cheers, > > Mike >

Dec. 30, 2017

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