On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > "A Smalltalk Image is your entire system. The Image includes all the tools > required to interact, customize and add functionality to your system, so > Smalltalk’s IDE is a very Integrated Development Environment." > > > Thats not the case even for someone like me that has been working with > smalltalk for only 2 years. The Image is not even the engine that drives > smalltalk . Thats the job of the VM that exists in a completely different > universe than smalltalk. It exists in the same universe than many other > languages do exists and thats the C universe, the universe of the OS. > Essentially what drives your system is not smalltalk is C. The diffirence is > that for a part of it that is high level enough, Slang is used, a Hybrid > language between C and Smalltalk that compiles to C. So while in the image > everything is , well almost everything, an object all the way down, in the > VM everything is C all the way down.
To take that argument further, the VM is not even the thing driving the image ;). Essentially what drives it are the 1's and 0's of machine code. Further, what drives that are the electrons flowing through the chip. I think its fair to say that we *code* in Pharo without files. Files relate to Pharo only to the same extent that a database like Oracle or Postgres can be said to use files. That is, when you do SQL queries, are you *thinking* in terms of files, even though files are used by the server to store the data? Its just a matter of where you draw the line of abstraction. cheers -ben > Ironically an image misses the most important tool to even generate this C > code and thats the VMMaker that has to be installed separately. And of > course there are parts of the system that are coded in pure C, like some > core functionalities of the VM and of course plugins and external libraries > that the image has to rely on make things happen. > > Of course the image is still fairly powerful, you can change the syntax, > implement high level libraries, IDE tools and much more. But its not the > core of the system just another essential part of it. > > > On Mon, Dec 7, 2015 at 9:24 AM Dimitris Chloupis <kilon.al...@gmail.com> > wrote: >>> >>> >>> well, i wouldn't need or even want it in memory, so on disk is fine. the >>> problem is more likely management of the same. browsing the changes is >>> not >>> really convenient. ideally i'd like to see versions in the class-browser >>> and >>> in the debugger, where on error i could then take a look at older >>> versions for >>> comparison, and switch to them to see if maybe the last change was the >>> cause of >>> the error. >>> >>> greetings, martin. >>> >> >> There are versions already for methods. So the functionality is there. >> >> I disagree however with you, I think that changes file was created for the >> precise scenarios of an image crash/ lockdown. In that case you may want to >> go back through the code and dont remember which method was triggered or >> what else was defined and created. In the case going chronologically which >> is how the changes file is already organised is far more useful than going >> method and class based. >> >> But I do agree it would be useful to extend the tools working with changes >> , but then none stop anyone from doing so and is not that hard to do.
