May 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] #ast vs. #parseTree

by Sean P. DeNigris

Marcus Denker-4 wrote > the cached #ast is for one interestingâ¦ Thanks! Very interesting :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 2, 2018

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by Sean P. DeNigris

Marcus Denker-4 wrote > (I sometimes wonder if we should not late-bind accesses to globals, that > is, just compile them as message sends to the environment). That would be *great*. This is another one of those little lies where "everything is a message send" and "late binding everything" breaks down, like inlining boolean/undefined ops, that can confuse/shock newbies. It probably made sense given the tech constraints at the time, but it would be wonderful not only to increase the beauty and simplicity of the system, but for the possibilities it opens up! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 2, 2018

Re: [Pharo-users] Using secure websockets server side with Zinc

by Cyril Ferlicot D.

On 02/05/2018 16:29, Sven Van Caekenberghe wrote: > Hi Cyril, > Thank you for the infos and the fast reply :) > You can run a ZnSecureServer with a specific certificate. See the class comment. But, this is a bit experimental, you need a very specific certificate and I have only seen it work on Linux. > Good to know! > If you front you Seaside app with Nginx, I assume you are doing HTTPS -> HTTP in Nginx. I would suggest you try doing WWS -> WS as well. This does mean that connections are kept open of course (implicit in WebSockets). I have not yet done this myself, but it should work theoretically. > This is what I do now and it works fine. I just wanted to know if there was an alternative to write it in the documentation of the project (since it will be open source). > The thing is, you will find 100x more info on (correct) TLS/SSL setup on Nginx, and app proxying is totally accepted today. > Ok, so I'll probably just give an example with nginx in the documentation :) > Please let us know how it goes ;-) > > Sven > > -- Cyril Ferlicot https://ferlicot.fr

May 2, 2018

Re: [Pharo-users] Using secure websockets server side with Zinc

by Sven Van Caekenberghe

Hi Cyril, You can run a ZnSecureServer with a specific certificate. See the class comment. But, this is a bit experimental, you need a very specific certificate and I have only seen it work on Linux. If you front you Seaside app with Nginx, I assume you are doing HTTPS -> HTTP in Nginx. I would suggest you try doing WWS -> WS as well. This does mean that connections are kept open of course (implicit in WebSockets). I have not yet done this myself, but it should work theoretically. The thing is, you will find 100x more info on (correct) TLS/SSL setup on Nginx, and app proxying is totally accepted today. Please let us know how it goes ;-) Sven > On 2 May 2018, at 16:21, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Hi! > > I am trying to deploy a Seaside application that uses Zinc's websockets. > > I use nginx and I have a TLS certificate for the application so I need > to use secure websockets (wss://) and not simple websockets (ws://). > > I got a problem because the client could not access to the server > because it was failing the handshake. > > I could make it work by using nginx to manage the certificate. But I was > wondering if it would be possible with Zinc to give the access to the > certificate to manage the connection instead of doing it via nginx. Is > it possible to do this? > > Thanks in advance. > > -- > Cyril Ferlicot > https://ferlicot.fr >

May 2, 2018

Using secure websockets server side with Zinc

by Cyril Ferlicot D.

Hi! I am trying to deploy a Seaside application that uses Zinc's websockets. I use nginx and I have a TLS certificate for the application so I need to use secure websockets (wss://) and not simple websockets (ws://). I got a problem because the client could not access to the server because it was failing the handshake. I could make it work by using nginx to manage the certificate. But I was wondering if it would be possible with Zinc to give the access to the certificate to manage the connection instead of doing it via nginx. Is it possible to do this? Thanks in advance. -- Cyril Ferlicot https://ferlicot.fr

May 2, 2018

Re: [Pharo-users] Iceberg Pharo6.1 on Microsoft Windows 7

by Guillermo Polito

Hi Federico, I don't think compiling libgit in your box will solve the problem. I think libgit is correctly compiled (otherwise you'd have another kind of error). What you probably have is an ssh authentication error. Could you try cloning using the https url provided by github instead? That should generally solve your problem. The other thing is that the version of iceberg in pharo 6 is really outdated. We will soon backport the new version, I'll keep everybody posted in this mailing list. Otherwise, you can test latest Pharo 7, with the latest Iceberg version. The issue tracker is here: https://github.com/pharo-vcs/iceberg/issues Tx, Guille On Wed, May 2, 2018 at 2:01 PM, Federico.Balaguer < federico.balaguer(a)gmail.com> wrote: > Hello, > > I am trying to help some newbies to Smalltalk to use Iceberg on Pharo6.1 on > Windows 7. > I have a VirtualBox with Windows 7, I have the PharoLauncher installed from > where I launch the Pharo 6.1 image. > > I cannot clone github repositories, I get a debugger: "LGit_GIT_ERROR: > failed to get server certificate: The handle is in the wrong state for the > requested operation" > > Do I have to compile libgit or libgit2 on the MSWindows virtual machine? > > thanks. federico > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 2, 2018

Re: [Pharo-users] #ast vs. #parseTree

by Marcus Denker

> On 27 Apr 2018, at 21:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Marcus Denker-4 wrote >> I will add commentsâ¦ > > I got confused by this again and created an issue: > https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-… > > And then Peter Uhnak reminded me on Discord about this thread. I'm happy to > add the comments, but not sure I understand the issue well enough. IIUC #ast > is cached, but #parseTree is not. What I don't understand is the purpose of > this difference and when one would use one over the other. the cached #ast is for one interesting for speed (that is, in situations where you ask for it often). The other use-case is if you want to annotate the AST and keep that annotation around (till the next image save, but you can subscribe to ASTCacheReset and re-install the AST in the cache after cleaning. (This is used by MetaLinks to make sure they survive image restart). The last thing that it provides is that we do have a quite powerful mapping between bytecode/text/context and the AST. Regardless how you navigate, you get the same object. e.g. even this one works: [ 1+2 ] sourceNode == thisContext method ast blockNodes first > For example, > when, if ever, would a user want to access a CM's #ast (as opposed to > #parseTree) and could modifying it create problems? > Modification is a problem, yes.. code that wants to modify the AST without making sure the compiledMethod is in sync later should use #parseTree. Code that does not modify the AST (or makes sure to compile it after modification) is free to use #ast. or if you want to annotate the AST (which is a modification, after all). This is not perfect (not at allâ¦) but the simplest solution to get (to some extend) what you would have if the system would have a real persistent, first class ASTâ¦ To be improved. The ASTCache with itâs naive âlets just cache everything till the next image saveâ was done with the idea to see when it would show that it is too naiveâ¦ for that it worked amazingly well till now. Marcus

May 2, 2018

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by Marcus Denker

> On 2 May 2018, at 14:39, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Well, yes to both. > > Now, about the performance, first I'd like to have a benchmark suite that runs all the time, to at least understand if we lose some performance, when/why was it. > Of course, this would have an impact depending on how often are globals read/written. But I'd like to know with more certainty. > > Also > > [SystemNavigation new isUsedClass: IceRepository] bench > => '172.497 per second' > Only if it finds the class fastâ¦ you need to search for a not used one to see the worst case. > So maybe we can pay the price of a couple of milliseconds every time we remove a class for the moment. I prefer a "bit slower" system that is more robust :) > Also, how often do we remove classes? I don't think this is critical, and the robustness here pays for itself :) > We can think about how to optimize it later. > Yes, we do not remove classes that often. Marcus

May 2, 2018

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by Guillermo Polito

Well, yes to both. Now, about the performance, first I'd like to have a benchmark suite that runs all the time, to at least understand if we lose some performance, when/why was it. Of course, this would have an impact depending on how often are globals read/written. But I'd like to know with more certainty. Also [SystemNavigation new isUsedClass: IceRepository] bench => '172.497 per second' So maybe we can pay the price of a couple of milliseconds every time we remove a class for the moment. I prefer a "bit slower" system that is more robust :) Also, how often do we remove classes? I don't think this is critical, and the robustness here pays for itself :) We can think about how to optimize it later. Guille On Wed, May 2, 2018 at 2:20 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Two points. > > 1. Maybe we should centralize the removal of a class in a component as the > class installer. So we can have it all in one place, and if we need to > override and do fancy stuff. > 2. Yes to the messages to the environment, I am doing so to have multiple > environments sharing the same methods. We can check how much does it affect > the performance, because it opens a lot of different options to extend the > language. > > Cheers, > Pablo > > On Wed, May 2, 2018 at 2:09 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> >> > On 26 Apr 2018, at 09:28, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > >> > Hi, >> > >> > It looks you got bit by this issue: >> > >> > https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-doe >> s-not-work-well-with-Undeclareds >> > >> > It's not particular to Epicea. There should be a better management of >> Undeclareds in general in all Pharo. >> > >> >> It can be fixed by moving the binding to undeclared in #removeFromSystem: >> >> This is done by adding >> >> Undeclared declare: self name asSymbol from: Smalltalk globals. >> >> before the "forgetClass: self logged:" line. >> >> What we need to do in addition: Only do that when the class is >> referenced. #isUsedClass: does that, but it does integrate over all methods >> in the system. >> >> (I sometimes wonder if we should not late-bind accesses to globals, that >> is, just compile them as message sends to the environment). >> >> Marcus >> >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 2, 2018

Re: [Pharo-users] Restoring a class via Epicea didn't recompile a reference?

by tesonep＠gmail.com

Two points. 1. Maybe we should centralize the removal of a class in a component as the class installer. So we can have it all in one place, and if we need to override and do fancy stuff. 2. Yes to the messages to the environment, I am doing so to have multiple environments sharing the same methods. We can check how much does it affect the performance, because it opens a lot of different options to extend the language. Cheers, Pablo On Wed, May 2, 2018 at 2:09 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On 26 Apr 2018, at 09:28, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > Hi, > > > > It looks you got bit by this issue: > > > > https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem- > does-not-work-well-with-Undeclareds > > > > It's not particular to Epicea. There should be a better management of > Undeclareds in general in all Pharo. > > > > It can be fixed by moving the binding to undeclared in #removeFromSystem: > > This is done by adding > > Undeclared declare: self name asSymbol from: Smalltalk globals. > > before the "forgetClass: self logged:" line. > > What we need to do in addition: Only do that when the class is referenced. > #isUsedClass: does that, but it does integrate over all methods in the > system. > > (I sometimes wonder if we should not late-bind accesses to globals, that > is, just compile them as message sends to the environment). > > Marcus > > > -- Pablo Tesone. tesonep(a)gmail.com

May 2, 2018