November 2016 - Pharo-dev - lists.pharo.org

Please test new VMs (round one)

by Esteban Lorenzano

Hi guys, I want to start moving the VM stuff into the new structure. Now I know there are still missing things :) Can you download a VM from here: https://bintray.com/estebanlm/pharo-vm/build/201611082123#files <https://bintray.com/estebanlm/pharo-vm/build/201611082123#files> and start using it, and report problems? thanks! Esteban ps: Windows users: Iâm still not there, Iâm having problems to build third-party libraries with cygwinâ¦ also if someone can help me here I would thank it :)

Nov. 9, 2016

[ann] petitparser2

by Tudor Girba

Hi, I am happy to announce the availability of PetitParser2, a wonderful redesign of the original PetitParser developed by Jan KurÅ¡. https://github.com/kursjan/petitparser2 Highlights: - it introduces the compiler facility that speeds up parsers by a factor of ~2-5x - it introduces the possibility of parsing streams without having them in memory - it comes with a new structure internally that makes it more flexible - it introduces asPParser (not a typo) to be able to have the new version working in parallel with the classic asParser The version is already present in the latest Moose 6.1 in parallel with PetitParser. Also, several of the parsers that are shipping with PetitParser were already copied to PetitParser2 as well. You can find more details here: http://www.humane-assessment.com/blog/introducing-petitparser2/ Some more documentation will follow. I think Jan did a wonderful job and the result is quite exciting. Please take a look and let us know what you think. Cheers, Doru -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

Nov. 8, 2016

Re: [Pharo-dev] http://pharo.org/files/pharo.png

by Sven Van Caekenberghe

Super, thank you Esteban! > On 8 Nov 2016, at 13:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > sorry for taking so longâ¦ yesterday I had a mess in my head with different stuff. > I added the correct redirect and now http://pharo.org/files/pharo.png answers correct file (I just added a redirect rule as this was the easiest/way to fix this problem). > > Esteban > >> On 6 Nov 2016, at 23:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 6 Nov 2016, at 22:04, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> >>>> On 6 Nov 2016, at 19:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> I am not upset, but you did not explain what you did up until now. >>>> >>>> Still, this URL was/is used everywhere as an example (in comments and books) and tests. >>>> >>>> It looks silly if we break our own links. And a year or so ago I already changed all those links once. If I have to do it again, I will move everything away from infrastructure that I cannot control myself. >>> >>> I didnât know I was breaking anythingâ¦ otherwise I would have fixed it, is not that I looked at it and I said âhey, letâs break thisâ¦ who cares?â >>> Now, I need to fix itâ¦ as many other things that we may break without knowingâ¦ thatâs why I said, and I repeat: âwe all make mistakes time to timeâ. >> >> OK, of course you did not do this on purpose. And it is good that you maintain the main website. >> >> Now, it is common/good practice to front Seaside with nginx (or apache). If you do, you can export the Seaside files to the file system (using #deployFiles) to serve them faster/better when found. Like this: >> >> upstream my-seaside { >> ip_hash; >> server localhost:9090; >> ... >> } >> >> server { >> ... >> >> location /files { >> alias /home/pharo/my-files; >> try_files $uri @seaside; >> gzip on; >> gzip_types application/x-javascript text/css; >> expires 30d; >> } >> >> location / { >> proxy_pass http://my-seaside; >> add_header X-Server Pharo; >> } >> >> location @seaside { >> proxy_pass http://my-seaside; >> add_header X-Server Pharo; >> } >> } >> >> With this scheme you should be able to add any statically served file manually. (Here only under /files, but you could add more handlers). >> >> Sven >> >>> Esteban >>> >>>> >>>>> On 6 Nov 2016, at 19:02, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> It is not removedâ¦ I moved the backend from amber to seaside and there is a problem because standard installation of seaside uses /files to his own file server. >>>>> now, I want to move that but I didnât had the time. >>>>> In the mean time, in fact real address of that file was before and still is: https://pharo.org/web/files/pharo.png >>>>> and file can still be found there. >>>>> >>>>> Iâm sorry if I messes up something, but I see no reason to be so upsetâ¦ we all make mistakes time to time :P >>>>> >>>>> Esteban >>>>> >>>>>> On 6 Nov 2016, at 18:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>> Who removed http://pharo.org/files/pharo.png ? >>>>>> >>>>>> Why ? >>>>>> >>>>>> It is used in tests/examples. >>>>>> >>>>>> Could it be put back please, even it is not used (it does do no harm) ? >>>>>> >>>>>> A basic rule of the Web is not to break existing stuff. >>>>>> >>>>>> Sven >> >> >

Nov. 8, 2016

Re: [Pharo-dev] http://pharo.org/files/pharo.png

by Esteban Lorenzano

sorry for taking so longâ¦ yesterday I had a mess in my head with different stuff. I added the correct redirect and now http://pharo.org/files/pharo.png <http://pharo.org/files/pharo.png> answers correct file (I just added a redirect rule as this was the easiest/way to fix this problem). Esteban > On 6 Nov 2016, at 23:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 6 Nov 2016, at 22:04, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >>> On 6 Nov 2016, at 19:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> I am not upset, but you did not explain what you did up until now. >>> >>> Still, this URL was/is used everywhere as an example (in comments and books) and tests. >>> >>> It looks silly if we break our own links. And a year or so ago I already changed all those links once. If I have to do it again, I will move everything away from infrastructure that I cannot control myself. >> >> I didnât know I was breaking anythingâ¦ otherwise I would have fixed it, is not that I looked at it and I said âhey, letâs break thisâ¦ who cares?â >> Now, I need to fix itâ¦ as many other things that we may break without knowingâ¦ thatâs why I said, and I repeat: âwe all make mistakes time to timeâ. > > OK, of course you did not do this on purpose. And it is good that you maintain the main website. > > Now, it is common/good practice to front Seaside with nginx (or apache). If you do, you can export the Seaside files to the file system (using #deployFiles) to serve them faster/better when found. Like this: > > upstream my-seaside { > ip_hash; > server localhost:9090; > ... > } > > server { > ... > > location /files { > alias /home/pharo/my-files; > try_files $uri @seaside; > gzip on; > gzip_types application/x-javascript text/css; > expires 30d; > } > > location / { > proxy_pass http://my-seaside; > add_header X-Server Pharo; > } > > location @seaside { > proxy_pass http://my-seaside; > add_header X-Server Pharo; > } > } > > With this scheme you should be able to add any statically served file manually. (Here only under /files, but you could add more handlers). > > Sven > >> Esteban >> >>> >>>> On 6 Nov 2016, at 19:02, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> It is not removedâ¦ I moved the backend from amber to seaside and there is a problem because standard installation of seaside uses /files to his own file server. >>>> now, I want to move that but I didnât had the time. >>>> In the mean time, in fact real address of that file was before and still is: https://pharo.org/web/files/pharo.png >>>> and file can still be found there. >>>> >>>> Iâm sorry if I messes up something, but I see no reason to be so upsetâ¦ we all make mistakes time to time :P >>>> >>>> Esteban >>>> >>>>> On 6 Nov 2016, at 18:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> Who removed http://pharo.org/files/pharo.png ? >>>>> >>>>> Why ? >>>>> >>>>> It is used in tests/examples. >>>>> >>>>> Could it be put back please, even it is not used (it does do no harm) ? >>>>> >>>>> A basic rule of the Web is not to break existing stuff. >>>>> >>>>> Sven > >

Nov. 8, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60285 Home: https://github.com/pharo-project/pharo-core

Nov. 8, 2016

[pharo-project/pharo-core] e69cad: 60285

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e69cad77c5e38882959244a89140d07bd29591fa https://github.com/pharo-project/pharo-core/commit/e69cad77c5e38882959244a8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-08 (Tue, 08 Nov 2016) Changed paths: A Nautilus.package/CodeRefactoringAcceptor.class/README.md A Nautilus.package/CodeRefactoringAcceptor.class/definition.st A Nautilus.package/CodeRefactoringAcceptor.class/instance/protocol/accept_notifying_.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/rewrite code/categoryRegex.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/rewrite code/classRegex.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/rewrite code/protocolRegex.st M NautilusRefactoring.package/NautilusRefactoring.class/instance/rewrite code/sourceRegex.st A NautilusRefactoring.package/extension/NautilusUI/instance/refactorCode_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60284.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60285.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60284.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60285.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R System-Support.package/VirtualMachine.class/instance/modules/loadModule_.st M Tool-Base.package/MethodClassifier.class/instance/classification/classify_.st Log Message: ----------- 60285 18146 VirtualMachine>>loadModule: always fails https://pharo.fogbugz.com/f/cases/18146 19267 Can not accept "Code Rewrite" template for regex refactorings https://pharo.fogbugz.com/f/cases/19267 19317 MethodClassifier order should be changed https://pharo.fogbugz.com/f/cases/19317 http://files.pharo.org/image/60/60285.zip

Nov. 8, 2016

Re: [Pharo-dev] pillar latex and code listings

by Nicolai Hess

2016-11-08 9:32 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-11-07 23:47 GMT+01:00 Damien Pollet <damien.pollet(a)gmail.com>: > >> On 7 November 2016 at 23:03, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >>> I look at the pdf for the update PBE and the references to code example >>> don't >>> work (just show ??, it works for figures). >>> >> >> Could be that the reference or label simply don't matchâ¦ >> > > But it is the same source that works for the html output. > > >> >> >>> The code in the code example isn't highlight and >>> does't have a dark background (as it is in the html output). >>> >> >> Don't expect PDF and HTML to look the same. >> > > Yes, but the latext template at least looks like the listing for smalltalk > language at least should recognize some syntax words (self/super/...) > > >> Pillar does its job at a semantic level, not at form level. Both have >> their own independent way of styling stuff. For LaTeX it relies on a >> specific document class setup, including some macros to have a layer of >> decoupling between pillar's output and what some packages offer. The >> listing environment you're mentioning is an example; I haven't looked at >> pre-EnterprisePharo books in a while, but it should indeed just be defined >> as an alias to the lstlisting provided by listings.sty. >> > > OK, I 'll check this. > > >> >> BTW I'd recommend migrating the books to the EnterprisePharo layoutâ¦ but >> that requires being somehow versed in the dark arts of LaTeX and ready to >> spend a couple days checking for problems and matching format conventionsâ¦ >> > Hm, the Enterprise book does not use named scripts or refer to scripts in the text, I don't know, maybe it doesn't work even there. > >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > >

Nov. 8, 2016

Re: [Pharo-dev] pillar latex and code listings

by Nicolai Hess

2016-11-07 23:47 GMT+01:00 Damien Pollet <damien.pollet(a)gmail.com>: > On 7 November 2016 at 23:03, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> I look at the pdf for the update PBE and the references to code example >> don't >> work (just show ??, it works for figures). >> > > Could be that the reference or label simply don't matchâ¦ > But it is the same source that works for the html output. > > >> The code in the code example isn't highlight and >> does't have a dark background (as it is in the html output). >> > > Don't expect PDF and HTML to look the same. > Yes, but the latext template at least looks like the listing for smalltalk language at least should recognize some syntax words (self/super/...) > Pillar does its job at a semantic level, not at form level. Both have > their own independent way of styling stuff. For LaTeX it relies on a > specific document class setup, including some macros to have a layer of > decoupling between pillar's output and what some packages offer. The > listing environment you're mentioning is an example; I haven't looked at > pre-EnterprisePharo books in a while, but it should indeed just be defined > as an alias to the lstlisting provided by listings.sty. > OK, I 'll check this. > > BTW I'd recommend migrating the books to the EnterprisePharo layoutâ¦ but > that requires being somehow versed in the dark arts of LaTeX and ready to > spend a couple days checking for problems and matching format conventionsâ¦ > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Nov. 8, 2016

Re: [Pharo-dev] pillar latex and code listings

by Damien Pollet

On 7 November 2016 at 23:03, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > I look at the pdf for the update PBE and the references to code example > don't > work (just show ??, it works for figures). > Could be that the reference or label simply don't matchâ¦ > The code in the code example isn't highlight and > does't have a dark background (as it is in the html output). > Don't expect PDF and HTML to look the same. Pillar does its job at a semantic level, not at form level. Both have their own independent way of styling stuff. For LaTeX it relies on a specific document class setup, including some macros to have a layer of decoupling between pillar's output and what some packages offer. The listing environment you're mentioning is an example; I haven't looked at pre-EnterprisePharo books in a while, but it should indeed just be defined as an alias to the lstlisting provided by listings.sty. BTW I'd recommend migrating the books to the EnterprisePharo layoutâ¦ but that requires being somehow versed in the dark arts of LaTeX and ready to spend a couple days checking for problems and matching format conventionsâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Nov. 7, 2016

pillar latex and code listings

by Nicolai Hess

How are latex output of (named) code listings supposed to work /look ? I look at the pdf for the update PBE and the references to code example don't work (just show ??, it works for figures). The code in the code example isn't highlight and does't have a dark background (as it is in the html output). The generated tex looks like this: \begin{listing}[caption={Decomposing aPen go: 100 + 20}, label=scr:decColor2, language=smalltalk] aPen go: 100 + 20 (1) 100 + 20 "binary message first" --> 120 (2) aPen go: 120 "then keyword message" \end{listing} the pdf output: Any idea what is wrong ? Is a postprocessing step necessary ? Should it be \begin{lstlisting} instead of \begin{listing} ?

Nov. 7, 2016