That's the thing you can't take the argument further without diminishing
the value of you argument precisely for the fact that the vm is far closer
related to the image than it is to 0s and 1s. That tight relation is
fundamental to the behavior and existence of the image. It defines its
functionality, purpose and limitations.
The image itself is a file and the fact that it can store live state in a
binary format does not make it unique or any less of a file. In my case I
use blender files, they store the entire live state of the blender window
including images and even Python scripts. Similar examples are countless
out there.
So the answer to the question what makes the image file format unique is
simply.... Nothing
What's the advantage of using the image format compared to other files ?
None
On Mon, 7 Dec 2015 at 15:14, Ben Coman <
[hidden email]> wrote:
> On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis <
[hidden email]>
> 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 <
[hidden email]>
> > 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.
>
>