- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bad baseline practices

by Norbert Hartl

> Am 16.01.2019 um 09:42 schrieb Stephan Eggermont <stephan(a)stack.nl>: > > Cyril Ferlicot <cyril.ferlicot(a)gmail.com> > wrote: >> On Tue, Jan 15, 2019 at 6:03 PM Stephan Eggermont via Pharo-dev >> <pharo-dev(a)lists.pharo.org> wrote: >>> >>> >>> >>> Iâm not sure why, but Iâve noticed baselines being changed to refer to >>> patch versions for releases. Why are the old configuration problems >>> repeated? >> >> Which project are you talking about? > > In a plain Pharo 7 image > > BaselineOfCalypso > BaselineOfCommander > BaselineOfSystemCommands > > Stephan > Wasnât the problem that the wildcard notation is likely to hit the github API request limit? Norbert

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Stephan Eggermont

Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > following the meeting we had here @Inria headquarters, I'll be backporting > some of the improvements we did in the launcher this last month regarding > the encoding of environment variables. > > I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ > > We have already studied possible alternatives with Pablo and Christophe and > we have some conclusions and we propose some changes: > > API Proposal for OSEnvironment > ========================= > > > - > *at: aVariableName * > > Gets the String value of an environment variable called `aVariableName` > It is the system reponsibility to manage the encoding. > Rationale: A common denominator for all platforms providing an already > decoded string, because windows does not (compared to *nix systems) provide > a encoded byte representation of the value. Windows has instead its own > wide string representation. > > - *[optionally] rawAt: anEncodedVariableName* > > Gets the Byte value of an environment variable called > `anEncodedVariableName`. > It is the user responsibility to encode and decode argument and return > values in the encoding of this preference. > Rationale: Some systems may want to have the liberty to use different > encodings, or even to put binary data in the variables. > > - *[optionally] at: aVariableName encoding: anEncoding* > > Gets the value of an environment variable called `aVariableName` using > `anEncoding` to encode/decode arguments and return values. > Rationale: *xes could potentially use different encodings for their > environment variables or even use different encodings in different parts of > their file system. > > Other Implementation details > ========================= > > - VM primitives returning paths Strings should be carefuly managed to > decode them, since they are actually C strings (so byte arrays) disguised > as ByteStrings. > - Windows requires calling the right *Wide version of the functions from > C, plus the correct encoding routine. This could be implemented as an FFI > call or by modifying the VM to do it properly instead of calling the Ascii > version > > What is the conclusion from this and issue 22658? See PR 2238. #getEnv: is public API Stephan

Jan. 16, 2019

Re: [Pharo-dev] Bad baseline practices

by Stephan Eggermont

Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Tue, Jan 15, 2019 at 6:03 PM Stephan Eggermont via Pharo-dev > <pharo-dev(a)lists.pharo.org> wrote: >> >> >> >> Iâm not sure why, but Iâve noticed baselines being changed to refer to >> patch versions for releases. Why are the old configuration problems >> repeated? > > Which project are you talking about? In a plain Pharo 7 image BaselineOfCalypso BaselineOfCommander BaselineOfSystemCommands Stephan

Jan. 16, 2019

Re: [Pharo-dev] IceGitHubError API rate limit exceeded

by Paul DeBruicker

hi - Once you get a no-scope token from https://github.com/settings/tokens You can configure Monticello to use it to access github by running MCGitHubRepository siteUsername: 'myUsername' sitePassword: 'token' Paul DeBruicker wrote > github allows 60 unauthenticated requests per hour per IP. IF you > authenticate your requests you can make 5,000 per hour. If you don't want > to wait an hour after hitting this error you should create a personal, no > scope token following the instructions here: > https://blog.github.com/2013-05-16-personal-api-tokens/ The no-scope token > can only be used to read public repository information and cannot make any > changes to any of your repos. > > You can use the token to authenticate your requests by setting your github > username as the username and the token as the password in a HTTP basic > authentication request to their servers. > > I know ZnClient has #username:password: and so guess that Iceberg has or > can > have a similar method. > > Dont share the token. > > > > bpi wrote >> Hi, >> >> I followed these instructions for contributing to Pharo: >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> During Step 1 Repairing local repository missing I get the following >> error: >> IceGitHubError: API rate limit exceeded >> >> I retried with a new Pharo 7.0 - 64bit (development version) in Pharo >> Launcher and got the same error. >> >> I searched the mailing list but did not find anything. Am I really the >> only one who ever encountered this? Any tips? >> >> Cheers, >> Bernhard > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 16, 2019

Re: [Pharo-dev] Apparently Zodiac plugin can crash VM on Linux

by Sven Van Caekenberghe

Doing HTTPS client calls is part of the standard test suite, so it should work, else we would not have a green build. What exactly is he doing ? Is it reproducible ? Can he try with a fresh downloaded image+vm ? > On 15 Jan 2019, at 22:20, Max Leske <maxleske(a)gmail.com> wrote: > > Hi, > > I'm writing on behalf of Martin (eMBee) who's experiencing crashes when using SSL. You can find a VM crash stack trace here: http://ws.stfx.eu/AKVNLUPMPGLG. > > He says he hasn't updated openssl since December 15th but that the crashes started to happen only recently (within the last couple of days). I asked him to try HTTP only connections and those work. The VM crashes immediately when using SSL. To me it looks like the cuplrit is the Zodiac plugin, or at least the library it works with. > > His system: > linux, fedora 29, and from the system reporter i get: Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo > CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > cheers, > Max

Jan. 15, 2019

Apparently Zodiac plugin can crash VM on Linux

by Max Leske

Hi, I'm writing on behalf of Martin (eMBee) who's experiencing crashes when using SSL. You can find a VM crash stack trace here: http://ws.stfx.eu/AKVNLUPMPGLG. He says he hasn't updated openssl since December 15th but that the crashes started to happen only recently (within the last couple of days). I asked him to try HTTP only connections and those work. The VM crashes immediately when using SSL. To me it looks like the cuplrit is the Zodiac plugin, or at least the library it works with. His system: linux, fedora 29, and from the system reporter i get: Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git cheers, Max

Jan. 15, 2019

Re: [Pharo-dev] wish for p8: parserewriter UI

by ducasse

> On 15 Jan 2019, at 20:34, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 15/01/2019 Ã 20:25, StÃ©phane Ducasse via Pharo-dev a Ã©crit : > > Wasn't it the work of Mark Rizun? First we should have something super simple: Package List Selection or class list selection one expression => a list of method found or a list of method rewrote like in the original RB tools https://refactory.com/tools/refactoring-browser/rewrite-tool Second we can integrate the tool of Yuriy to help us write some patterns. Third we could add the one mark. Stef > > -- > Cyril Ferlicot > https://ferlicot.fr >

Jan. 15, 2019

Re: [Pharo-dev] I am abandoning SqueakSource3, any takers?

by Tobias Pape

Hi, Sorry, I'm again late to reply. > On 05.01.2019, at 22:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Tobi, > > On Sat, Jan 5, 2019 at 1:28 PM Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hi all, > > since there's not a lot interest anymore in SqueakSource3, I'm giving up maintenanceship. > > Here's the project: > http://squeaksource.com/squeaksource3.html > Here's the current bug tracker: > https://github.com/krono/squeaksource3/issues > > It runs on Squeak, GemStone, and Pharo. > > There are a few instances out there, running without any problems. > > What are the instances? If I depend on any I may have to take upon maintainership ;-) The instances are: http://ss3.gemtalksystems.com/ http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource (btw: the only MC repo I know that can serve via https ;)) https://sdk.krestianstvo.org/sdk/ (running the latest version) I already shut down my own instances. Best regards -Tobias > > Any Takers? > -t > > _,,,^..^,,,_ > best, Eliot

Jan. 15, 2019

Re: [Pharo-dev] wish for p8: parserewriter UI

by Cyril Ferlicot D.

Le 15/01/2019 Ã 20:25, StÃ©phane Ducasse via Pharo-dev a Ã©critÂ : Wasn't it the work of Mark Rizun? -- Cyril Ferlicot https://ferlicot.fr

Jan. 15, 2019

wish for p8: parserewriter UI

by StÃ©phane Ducasse

Hi Iâm rewriting around 400 methods following a pattern that the parsetree rewritter could easily transform for me and I would love to have a UI and integrate the tools did by Yuriy to understand patterns as a default tool in the tool ecosystem. stef -------------------------------------------- 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

Jan. 15, 2019