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

Re: [Pharo-dev] [Ann] Fog 1.0.0-beta

by Santiago Bragagnolo

already a revision to do to the doc! Metacello new baseline: 'Fog'; repository: 'github://smartanvil/Fog/src'; load. El lun., 3 dic. 2018 a las 1:20, Santiago Bragagnolo (< santiagobragagnolo(a)gmail.com>) escribiÃ³: > Hi All! > > I have being working on releasing versions (i should do it more often). > I am happy to announce Fog v1.0.0-beta. I think I found a API that i like > enough. So, i took the courage to pass to 1. > > Thew new version changes many things: Redefines the roll of the session, > it minimize the roll of the connection, it cleans up the code, it defines a > more verbose but less magic API. It generates proxies for the contracts. > > It supports now all the types including: maps and arrays. > > Goodnight :) > > > Santiago > > > Fog > > Pharo Ethereum Driver > > Fog is a library that allows the user to connect to an ethereum based > blockchain data base. > > Is based on the Javascript canonical implementation done by Ethereum > community Ethereum Javascript API > <https://github.com/ethereum/wiki/wiki/JavaScript-API>. > <https://github.com/smartanvil/Fog#dependencies> > Download code <https://github.com/smartanvil/Fog#iceberg--baseline>Iceberg > / Baseline > > Metacello > new > baseline: 'Fog'; > repository: 'github://sbragagnolo/Fog/src'; > load. > >

Dec. 3, 2018

[Ann] Fog 1.0.0-beta

by Santiago Bragagnolo

Hi All! I have being working on releasing versions (i should do it more often). I am happy to announce Fog v1.0.0-beta. I think I found a API that i like enough. So, i took the courage to pass to 1. Thew new version changes many things: Redefines the roll of the session, it minimize the roll of the connection, it cleans up the code, it defines a more verbose but less magic API. It generates proxies for the contracts. It supports now all the types including: maps and arrays. Goodnight :) Santiago Fog Pharo Ethereum Driver Fog is a library that allows the user to connect to an ethereum based blockchain data base. Is based on the Javascript canonical implementation done by Ethereum community Ethereum Javascript API <https://github.com/ethereum/wiki/wiki/JavaScript-API>. <https://github.com/smartanvil/Fog#dependencies> Download code <https://github.com/smartanvil/Fog#iceberg--baseline>Iceberg / Baseline Metacello new baseline: 'Fog'; repository: 'github://sbragagnolo/Fog/src'; load.

Dec. 3, 2018

Re: [Pharo-dev] Version control of Playground scripts

by Sean P. DeNigris

Shaping1 wrote > Git, Iceberg, Monticello, and Metacello... However, Iâm not sure which of > these will dominate and which will be phased-out tl;dr: Use Iceberg and Metacello, which use git (for now, eventually there should be other mainstream options) and Monticello for you. If you're insterested in the gory details, see Ben's and my answers in this thread: http://forum.world.st/What-is-the-actual-way-of-managing-code-in-Pharo-tp50… I don't know of any great documentation on the newest Iceberg, because it is a brand new redesign of the other tool, but docs on v. 1 will get you in the spirit and then you can ask lots of questions on Discord. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 2, 2018

Re: [Pharo-dev] Version control of Playground scripts

by Shaping

Hi everyone. These bits on version control are helpful. Firmly anchored in VW, Iâm trying, on and off, to start a correct/robust Pharo 7 version-control protocol--a groove, a loop that is reliable and aligned with the latest tools, which I gather are Git, Iceberg, Monticello, and Metacello (but I could be wrong about that). However, Iâm not sure which of these will dominate and which will be phased-outâor will all continue to be used indefinitely? Iceberg seems newest and most preferred. Can someone point me to the most efficient way to learn how to use the latest version-control tools in Pharo? There is much to read, and I suspect that it is not all up to date. http://books.pharo.org/updated-pharo-by-example/pdf/2018-09-29-UpdatedPharo… mentions Monticello, but not Iceberg or Metacello. https://github.com/pharo-vcs/iceberg/blob/master/docs/Iceberg-glossary.md looks like a good place to start, but I can probably find much better guidance here on the list than from a Google search. Thanks. Shaping From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Norbert Hartl Sent: Thursday, November 29, 2018 04:32 To: Pharo Dev <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Version control of Playground scripts Am 29.11.2018 um 11:15 schrieb Christopher Fuhrman <christopher.fuhrman(a)inria.fr <mailto:christopher.fuhrman@inria.fr> >: On Wed, 28 Nov 2018 at 10:23, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> > wrote: Am 28.11.2018 um 09:38 schrieb Christopher Fuhrman <christopher.fuhrman(a)inria.fr <mailto:christopher.fuhrman@inria.fr> >: Knowing Playground files are saved on local disk, I got to thinking... What would be the risk(s) of using git outside Pharo, on the Playground files' directory? Has anyone tried that before? It is not a problem. I use this every day. Meaning all my repos have a scripts folder where I put my helper scripts. In the image I open this with âscriptsâ asFileReference inspect This is great. Thanks! so you get kind of a file browser of all the scripts. If you call the files with an extension of .st you get syntax highlighting. If you change a script with cmd-s the file gets modified and you can check into git. The problem here is that if you have modifications in the image you should commit that first because if you do on the scripts folder first the image working copy is detached and there is no easy way to commit your in-image changes. You would have to do a branch which is cumbersome. I'm a bit lost here: 1. Are you using Iceberg within Pharo (when you speak of "committing that first"), or are you using only git outside of Pharo? Also, I think it's possible to use a git repo with monticello? 2. I'm not an advanced git user, so how do I set up my Pharo image directory to work with the 'scripts' folder (again, with Iceberg if possible, as it seems to be the most user-friendly)? Thanks for your patience with my beginner questions. You are welcome. We like to share with people that want to know ;) The problem in understanding is a hard one. Using git means there are two repositories, one online in the git server and the working copy you checked out locally. When using pharo there is a third one and that is the working copy within your image. Having these two there is a number of conflicts possible. As pharo does not manage external resources like these scripts you can have trouble here. When you go to the command line and commit the script and you go back to pharo it tells you that you are in detached state. It means that the git index is not the same as it was when you loaded stuff via pharo. That is why I was saying that a good flow would first commit the pharo changes and then the ones on the command line. Hope this helps, Norbert Cheers, Christopher With the scripts in place I have developed a workflow of creating new images. I have a script that downloads a new image and renames it for the project. And if it finds a script scripts/prepare-image.st <http://prepare-image.st/> it gets executed. This contains metacello commands to load the project code and settings I need in a new image. This way it is super easy to create a new image for your work. And as all the scripts you use are on the filesystem there is usually no state in the image that needs to be transferred to a new image. Norbert

Dec. 1, 2018

Re: [Pharo-dev] InterruptedContext vs suspendedContext

by Eliot Miranda

Hi Andrei, Hi Thomas, Andrei, you are right; they are different and the difference is important. As you say, suspendedContext is the top (âhotâ) context in a processâs context chain, but interruptedContext is the context which sent the signal message that eventually raised the exception that invoked the debugger. suspendedContext is therefore where execution is in the process, but interruptedContext is where the debugger should show the stack. Thomas, because the exception system is implemented in Smalltalk the handling of the initial signal (eg in Object>>#halt), all the way to opening a debugger, is itself Smalltalk code, and exists as activations from suspendedContext to interruptedContext. The debugger, with help from the exception system, carefully hides this processing from the programmer. If it did not we would have to wade through many activations before we found where the exception occurred. When a process is interrupted by control period things are different. Here, another process handles opening the debugger and indeed suspendedContext and interruptedContext are the same. So the difference between suspendedContext and interruptedContext is vital to the debugger. Without it we would see the inner machinery of the exception system when errors or exceptions are raised. HTH _,,,^..^,,,_ (phone) > On Nov 30, 2018, at 7:42 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > From what I remember they are not always redundant, but I'm not 100% sure they are both needed. > > `suspendedContext` from Process is always the top context of a process. After execution actions like Step Into, Step Over, Step Through it will be the same as interruptedContext in the debugger. > > They will be different when opening the debugger as a result of an exception. > Exception>>#debug triggers the workflow for opening a debugger. This uses `self signalerContext` as the context that is being debugged. This is the context where the exception was raised and this will be put in the interruptedContext. As this point the execution of the current process is not over and it will continue up to `MorphicUIManager>>#debugProcess:context:label:fullView:notification: ` where the current process is suspended. At that point the two will be different, as suspendedContext will be the context of the method MorphicUIManager>>#debugProcess:context:label:fullView:notification: and the interruptedContext the context that triggered the exception. > > But it might be that they are not both needed. One possible option might be to force the process to step to the context that raised the exception when the debugger is created. For example in DebugSession>>process:context:. > Apart from when opening the debugger I do not know if there is another situation where those two can diverge. > > Cheers, > Andrei > >> On Fri, Nov 30, 2018 at 11:54 AM Thomas Dupriez <tdupriez(a)ens-paris-saclay.fr> wrote: >> Hello, >> >> >> Instances of DebugSession have an "interruptedContext" and an "interruptedProcess" instance variable. >> >> Instances of Process have a "suspendedContext" instance variable. >> >> Does someone know if there is a relation between the interruptedContext of a DebugSession and the suspendedContext of its interruptedProcess? At first glance it seems like these two variables are redundant and store the same Context. >> >> Thomas Dupriez

Dec. 1, 2018