January 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Understanding the role of the sources file

by Dimitris Chloupis

So I am correct that the image does not store the source code, and that the source code is stored in sources and changes. The only diffirence is that the objects have a source variable that points to the right place for finding the source code. This is the final text if you find anything incorrect please correct me --------------- 1. The virtual machine (VM) is the only component that is different for each operating system. The purpose of the VM is to take Pharo bytcode that is generated each time user accepts a piece of code and convert it to machine code in order to be executed. Pharo 4 comes with the Cog VM a very fast JIT VM. The VM executable is named: â¢ Pharo.exe for Windows; â¢ pharo for Linux ; and â¢ Pharo for OSX (inside a package also named Pharo.app). The other components below are portable across operating systems, and can be copied and run on any appropriate virtual machine. 2. The sources file contains source code for parts of Pharo that donât change frequently. Sources file is important because the image file format stores only the bytecode of live objects and not their source code. Typically a new sources file is generated once per major release of Pharo. For Pharo 4.0, this file is named PharoV40.sources. 3. The changes file logs of all source code modifications since the .sources file was generated. This facilitates a per method history for diffs or re- verting.That means that even if you dont manage to save the image file on a crash or you just forgot you can recover your changes from this file. Each release provides a near empty file named for the release, for example Pharo4.0.changes. 4. The image file provides a frozen in time snapshot of a running Pharo system. This is the file where the Pharo bytecode is stored and as such its a cross platform format. This is the heart of Pharo, containing the live state of all objects in the system (including classes and methods, since they are objects too). The file is named for the release (like Pharo4.0.image). The .image and .changes files provided by a Pharo release are the starting point for a live environment that you adapt to your needs. Essentially the image file containes the compiler of the language (not the VM) , the language parser, the IDE tools, many libraries and acts a bit like a virtual Operation System that runs on top of a Virtual Machine (VM), similarly to ISO files. As you work in Pharo, these files are modified, so you need to make sure that they are writable. The .image and .changes files are intimately linked and should always be kept together, with matching base filenames. Never edit them directly with a text editor, as .images holds your live object runtime memory, which indexes into the .changes files for the source. It is a good idea to keep a backup copy of the downloaded .image and .changes files so you can always start from a fresh image and reload your code. However the most efficient way for backing up code is to use a version control system that will provide an easier and powerful way to back up and track your changes. The four main component files above can be placed in the same directory, although itâs also possible to put the Virtual Machine and sources file in a separate directory where everyone has read-only access to them. If more than one image file is present in the same directory pharo will prompt you to choose an image file you want to load. Do whatever works best for your style of working and your operating system. On Wed, Jan 13, 2016 at 12:13 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 13 Jan 2016, at 10:57, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > I was adding a short description to the UPBE about sources file , I > always thought that the sources file is the file that contains the source > code of the image because the image file itself stores only the bytecode. > > > > However its just came to my attention that the sources file does not > contain code that is recently installed in the image. > > > > So how exactly the sources file works and what it is ? > > The main perspective is from the object point of view: methods are just > objects like everything else. In order to be executable they know their > byte codes (which might be JIT compiled on execution, but that is an > implementation detail) and they know their source code. > > Today we would probably just store the source code strings in the image > (maybe compressed) as memory is pretty cheap. But way back when Smalltalk > started, that was not the case. So they decided to map the source code out > to files. > > So method source code is a magic string (RemoteString) that points to some > position in a file. There are 2 files in use: the sources file and the > changes file. > > The sources file is a kind of snapshot of the source code of all methods > at the point of release of a major new version. That is why there is a Vxy > in their name. The source file never changes once created or renewed (a > process called generating the sources, see PharoSourcesCondenser). > > While developing and creating new versions of methods, the new source code > is appended to another file called the changes file, much like a > transaction log. This is also a safety mechanism to recover 'lost' changes. > > The changes file can contain multiple versions of a method. This can be > reduced in size using a process called condensing the changes, see > PharoChangesCondenser. > > On a new release, the changes file will be (almost) empty. > > HTH, > > Sven > > > >

Jan. 13, 2016

Re: [Pharo-users] Understanding the role of the sources file

by Sven Van Caekenberghe

> On 13 Jan 2016, at 10:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I was adding a short description to the UPBE about sources file , I always thought that the sources file is the file that contains the source code of the image because the image file itself stores only the bytecode. > > However its just came to my attention that the sources file does not contain code that is recently installed in the image. > > So how exactly the sources file works and what it is ? The main perspective is from the object point of view: methods are just objects like everything else. In order to be executable they know their byte codes (which might be JIT compiled on execution, but that is an implementation detail) and they know their source code. Today we would probably just store the source code strings in the image (maybe compressed) as memory is pretty cheap. But way back when Smalltalk started, that was not the case. So they decided to map the source code out to files. So method source code is a magic string (RemoteString) that points to some position in a file. There are 2 files in use: the sources file and the changes file. The sources file is a kind of snapshot of the source code of all methods at the point of release of a major new version. That is why there is a Vxy in their name. The source file never changes once created or renewed (a process called generating the sources, see PharoSourcesCondenser). While developing and creating new versions of methods, the new source code is appended to another file called the changes file, much like a transaction log. This is also a safety mechanism to recover 'lost' changes. The changes file can contain multiple versions of a method. This can be reduced in size using a process called condensing the changes, see PharoChangesCondenser. On a new release, the changes file will be (almost) empty. HTH, Sven

Jan. 13, 2016

Re: [Pharo-users] Understanding the role of the sources file

by Christophe Demarey

Le 13 janv. 2016 Ã 10:57, Dimitris Chloupis a Ã©crit : > I was adding a short description to the UPBE about sources file , I always thought that the sources file is the file that contains the source code of the image because the image file itself stores only the bytecode. > > However its just came to my attention that the sources file does not contain code that is recently installed in the image. > > So how exactly the sources file works and what it is ? If I understood well: - the sources file has all the source code of the released pharo version (when we generate this new source file PharoVXX.sources). - the changes file has the source code since the release.

Jan. 13, 2016

Understanding the role of the sources file

by Dimitris Chloupis

I was adding a short description to the UPBE about sources file , I always thought that the sources file is the file that contains the source code of the image because the image file itself stores only the bytecode. However its just came to my attention that the sources file does not contain code that is recently installed in the image. So how exactly the sources file works and what it is ?

Jan. 13, 2016

Re: [Pharo-users] [ann] gtdebugger in pharo 5.0

by Esteban Lorenzano

no, Iâm quite sure they are bugs :) I also believe the other tools do not have accept/cancel visible (they are in contextual menus), so maybe they should be there. Esteban > On 12 Jan 2016, at 23:24, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > Accept and Cancel buttons shouldn't be there > or should not act on if the codepane hasn't changed. > (every press on "accept" writes a new method version, although the contents didn't changed - tested on > Latest update: #50524 ) > > Most (all?) other tools don't have Accept/Cancel buttons. > > - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' > - is "stackTop" now gone ? I thought you wanted to add it to the stack ? > - thisContext is gone as well ? > - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon > is a dropdown menu with label "Bytecode" (since when do we put buttons in the title pane? > - the evaluator pane is shown as "dirty", as it does not make a difference if we > accept the text in this pane, there shouldn't be a dirty indicator. > - you can not use the inspector pane to change inst var values > - there is no way to refresh the inspector pane > > I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but > features. > > > nicolai > >

Jan. 12, 2016

Re: [Pharo-users] [ann] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: > the GTDebugger. As this is a significant change that might affect your > workflow, here is some background information to help you deal with the > change. > > First, you should know that the change is not irreversible and it is > easily possible to disabled the new debugger through a setting. However, > please do take the time to provide us feedback if something does not work > out for you. We want to know what can be improved and we try to react as > fast as we can. > > A practical change comes from the fact that the variables are manipulated > through a GTInspector, which makes it cheaper to maintain in the longer run. > Accept and Cancel buttons shouldn't be there or should not act on if the codepane hasn't changed. (every press on "accept" writes a new method version, although the contents didn't changed - tested on Latest update: #50524 ) Most (all?) other tools don't have Accept/Cancel buttons. - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' - is "stackTop" now gone ? I thought you wanted to add it to the stack ? - thisContext is gone as well ? - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon is a dropdown menu with label "Bytecode" (since when do we put buttons in the title pane? - the evaluator pane is shown as "dirty", as it does not make a difference if we accept the text in this pane, there shouldn't be a dirty indicator. - you can not use the inspector pane to change inst var values - there is no way to refresh the inspector pane I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but features. nicolai

Jan. 12, 2016

Re: [Pharo-users] SSL client certificates

by Norbert Hartl

> Am 12.01.2016 um 16:25 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Given a ZdcSecureSocketStream you can access the #sslSession. In this session object you can use #certificateName: to set the path or name of the certificate (before you #connect !). That is the general idea. > > Now, I don't know if this works or not. Be prepared to look in the plugin C code! On Linux this will probably work. > > And please let us know how it goes ;-) I tried on Mac OS and on Linux but no luck so far. I used | ip stream | ip := NetNameResolver addressForName: 'gateway.sandbox.push.apple.com' timeout: 5000. stream := ZdcSecureSocketStream openConnectionToHost: ip port: 2195 timeout: 3000. stream binary; shouldSignal: true; autoFlush: false; bufferSize: 16384; timeout: 5000. stream sslSession enableLogging; certificateName: '/root/my.pem'. stream connect. But I get ConnectionClosed: Connection closed while waiting for data. This is while doing the SSL handshake. On Linux the log is qSetStringPropertySSL(1): /root/my.pem sqConnectSSL: 8a69058 sqConnectSSL: Setting up SSL sqSetupSSL: setting method sqSetupSSL: Creating context sqSetupSSL: setting cipher list sqSetupSSL: Using cert file /root/my.pem sqSetupSSL: No root CA given; using default verify paths sqSetupSSL: Creating SSL sqSetupSSL: setting bios sqConnectSSL: Setting connect state sqConnectSSL: BIO_write 0 bytes sqConnectSSL: SSL_connect sqConnectSSL: sqCopyBioSSL sqCopyBioSSL: 297 bytes pending; buffer size 17408 sqConnectSSL: 8a69058 sqConnectSSL: BIO_write 3143 bytes sqConnectSSL: SSL_connect sqConnectSSL: sqCopyBioSSL sqCopyBioSSL: 2057 bytes pending; buffer size 17408 ConnectionClosed: Connection closed while waiting for data. [ ConnectionClosed signal: 'Connection closed while waiting for data.' ] in Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: 'Connection closed whil...etc... Socket>>waitForDataFor:ifClosed:ifTimedOut: Socket>>waitForDataFor: ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData ZdcSecureSocketStream>>readEncryptedBytes:startingAt:count: ZdcSecureSocketStream>>connect UndefinedObject>>DoIt I'm not sure what is going on and I believe it is rather hard to figure out what is the error exactly. Using $ openssl s_client -connect gateway.sandbox.push.apple.com:2195 -cert my.pem -debug -showcerts -CAfile entrust_2048_ca.cer it works. I don't know if the missing CA file is the culprit. But I doubt the squeak SSL code does verifying so it might be something else. Norbert > >> On 12 Jan 2016, at 16:05, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Is there a way to make SSL connections to the outside world using client certificates from pharo? >> >> thanks, >> >> Norbert >> >> >> > >

Jan. 12, 2016

Re: [Pharo-users] [ann] gtdebugger in pharo 5.0

by Nicolai Hess

Accept and Cancel buttons shouldn't be there or should not act on if the codepane hasn't changed. (every press on "accept" writes a new method version, although the contents didn't changed - tested on Latest update: #50524 ) 2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: > the GTDebugger. As this is a significant change that might affect your > workflow, here is some background information to help you deal with the > change. > > First, you should know that the change is not irreversible and it is > easily possible to disabled the new debugger through a setting. However, > please do take the time to provide us feedback if something does not work > out for you. We want to know what can be improved and we try to react as > fast as we can. > > A practical change comes from the fact that the variables are manipulated > through a GTInspector, which makes it cheaper to maintain in the longer run. > > > While the first thing that will capture the attention is the default > generic interface, the real power comes from the moldable nature of the > debugger. Like all other GT tools, GTDebugger is also moldable by design. > This means that we can construct custom debuggers for specific libraries at > small costs (often measured in a couple of hundred lines of code). > > > > Here is an introductory overview blog post that also includes some links > for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Beauty is where we see it." > > > > >

Jan. 12, 2016

Re: [Pharo-users] When Pharo 5 is to be released as stable ?

by Esteban A. Maringolo

2016-01-12 17:03 GMT-03:00 stepharo <stepharo(a)free.fr>: > Yes some stuff has to be done. Especially when a team is coming from the other part of the country to film us during one > complete week. We have 61 sessions + teaser recording. > I think that I will relax but we should prepare all the interactive videos showing pharo and the first exercise. > So this is why we need a stable UI. This is why I work on cleaning Nautilus this summer to avoid to have newcomers facing > too many glitches and this is why this is great that FastTable got improved by cyril and others. > So this is not that I did not plan in advance. > Also I gacve 3/4 full lectures with the mooc material to debug it for real. I spent in general two hours > after each day to improve the material. > So it means that after that teachers will have an excellent lectures support and mooc to teach Pharo. Wow. I look forward to see the MOOC. I can take the course as a tester of it if you want. Count with me on that. Regards! Esteban A. Maringolo

Jan. 12, 2016

Re: [Pharo-users] When Pharo 5 is to be released as stable ?

by stepharo

> Yeah I notice the frenzy of your commits in the pharo mooc github repo , Yes some stuff has to be done. Especially when a team is coming from the other part of the country to film us during one complete week. We have 61 sessions + teaser recording. I think that I will relax but we should prepare all the interactive videos showing pharo and the first exercise. So this is why we need a stable UI. This is why I work on cleaning Nautilus this summer to avoid to have newcomers facing too many glitches and this is why this is great that FastTable got improved by cyril and others. So this is not that I did not plan in advance. Also I gacve 3/4 full lectures with the mooc material to debug it for real. I spent in general two hours after each day to improve the material. So it means that after that teachers will have an excellent lectures support and mooc to teach Pharo. Stef > good luck and good rest afterwards , dont burnout :) > > On Tue, Jan 12, 2016 at 9:48 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > The Pharo mooc should start the 02 of May so we (the three amigos > spending our time on the mooc) would really like the mooc > to use Pharo 50 so early april is important for us else we will have a > mess. > > Stef > > Le 11/1/16 20:13, Esteban Lorenzano a Ã©crit : > > april > > > >> On 11 Jan 2016, at 19:55, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > >> > >> I am curious when is Pharo 5 is to be released as stable and > move to Pharo 6 , any idea ? > > > > > >

Jan. 12, 2016