whats the diffirence ?
On Tue, Dec 8, 2015 at 1:23 PM EuanM <euan...@gmail.com> wrote: > Again, you seem to be using "the image" mainly to mean "the .image file", > and only occassionally to mean the actual image itself. They are distinct > (albeit tightly related) things. > On 7 Dec 2015 22:09, "Dimitris Chloupis" <kilon.al...@gmail.com> wrote: > >> And this "victory of dead code and date" that files usually promote can >> further benefit Pharo . >> >> For example lets take one of the main problems of the Pharo image, its >> size. There is already an effort to modularilise the image to make it small >> and everything else installable and unistallable. >> >> But why not go a step further and have dead zone files. So you end up >> with a tiny image containing just the basics (few kbs if possible) even no >> GUI and IDE tools and instead you have a collection of files that can be >> read by the image , each file contains a diffirent project, you can view >> their code and their data but not install them in the image to do so. And >> only when you decide that "sure I could use this project" then you instruct >> the image to import the file and make the code and the data live and part >> of the image. This way the pharo system can keep growing without growing >> the image at all and let the users decide how much they want to grow the >> image themselves. >> >> Technically speaking this functionality is already available through >> monticello , where monticello allow you to view a local or remote >> repository of code without loading the code to the image (via the "open >> button"). So its not even a new concept. Though in my mind I imagine all >> this happening from inside the System Browser. >> >> Thats just one scenario how dead data and code can greatly benefit the >> Pharo system. I can keep brainstorming forever for the usefulness of files >> for Pharo. >> >> >> On Mon, Dec 7, 2015 at 9:20 PM horrido <horrido.hobb...@gmail.com> wrote: >> >>> You make a convincing argument. Files are useful. >>> >>> In modern circumstances, Smalltalk has to coexist with a file-based >>> world. >>> As Joachim wrote earlier, we are well-equipped to deal with files, but >>> we do >>> not think in terms of files when we code our applications. We are not >>> obliged to use a file-based toolchain. The point of my article was to >>> persuade other developers that letting their obsession with file-based >>> tools >>> prevent them from adopting Smalltalk is short-sighted and >>> counter-productive. Files have their uses, but they should look beyond >>> files >>> for other software creation possibilities. Smalltalk has much to offer. >>> >>> And, yes, it would be very good to have 64-bit support in Smalltalk. >>> >>> >>> >>> kilon.alios wrote >>> > The devil is in the details ;) >>> > >>> > It matters to me, I just came across the need to share data between >>> > multiple images. So I was pointed by the good people here to the Fuel >>> > library that , surprise surprise , it generates binary files that >>> contain >>> > objects in their live state that helps you move and share code and data >>> > between images. Works well and I really like its design :) >>> > >>> > We are not talking here about something sophisticated, we are talking >>> here >>> > super basic functionality. Images sharing data and code. What we use ? >>> > Files. The image by itself has no functionality to even cover this >>> super >>> > basic scenario because as a format is made to be self contained. >>> > >>> > How you cant even care for such basic functionality ? Of course you >>> will >>> > at >>> > some point. Its unavoidable. >>> > >>> > The nice thing about files is that they have one very big advantage >>> over >>> > the image. That is, specialization. When an app find a specific file , >>> > just >>> > by looking at its extension it immediately knows the structure of the >>> data >>> > and the code that it may contain. >>> > >>> > On other hand when you have an object system like the image is, such >>> > specifications go outside the window meaning you have to deal with the >>> > fact >>> > and trust that those that made those images have adhered to specific >>> > guidelines so you can make sure that your code wont run in front of >>> some >>> > very nasty surprises. >>> > >>> > But since the image itself allow you hack so deeply as the syntax of >>> the >>> > language , you can't be sure how the data and code will be presented. >>> Sure >>> > they will objects, but the format does not really matter so much as the >>> > structure itself. >>> > >>> > In those cases files win hands down because they tend to be far more >>> > restricted on how they are structured. Not because there is anything >>> > special to these files, apart from the fact that their authors made >>> sure >>> > to >>> > follow the specific structure to ensure compatibility with third party >>> > apps. >>> > >>> > So not only Files are not on the Stone Age but they have evolved the >>> level >>> > of specification to a whole new level that have made the foundation of >>> our >>> > every day lives. >>> > >>> > Sure you could probably replace files with a new way that is more >>> > Smalltalk >>> > friendly and still retain all the advantages of files and file system >>> but >>> > , >>> > Smalltalk has not presented such solution to my knowledge. Hence we the >>> > smalltalkers we will still keep relying heavily on files for our every >>> day >>> > needs until such solution is presented to us. Also with the huge >>> wealth of >>> > file formats it would be a pain in the ass to replace them with a >>> > smalltalk >>> > solution. >>> > >>> > In the mean time there are even more pressing matter that the image >>> file >>> > has to attend to, which is far more stone age , to use your remark , >>> than >>> > files. That is the ability to use full memory of the system and the >>> > ability >>> > to deal with large data without any large hits on performance. In short >>> > good support for 64 bit and big data. >>> > >>> > >>> > "But these are implementation details...implementation of the base >>> system. >>> > /From the perspective of a programmer writing an application/, none of >>> > this >>> > matters. >>> > >>> > As I said earlier, the only reason why Smalltalk has to deal with >>> files at >>> > all is because we live in a file-based culture. And the reason our >>> culture >>> > is so entrenched with files is because we are too heavily invested in >>> > them, >>> > and we aren't going to budge. *Files are about as low a storage >>> > abstraction >>> > as you can get*, and they pre-date even Unix. Yes, files belong in the >>> > Stone >>> > Age!" >>> > >>> > On Mon, Dec 7, 2015 at 6:45 PM horrido < >>> >>> > horrido.hobbies@ >>> >>> > > wrote: >>> > >>> >> But these are implementation details...implementation of the base >>> system. >>> >> /From the perspective of a programmer writing an application/, none of >>> >> this >>> >> matters. >>> >> >>> >> As I said earlier, the only reason why Smalltalk has to deal with >>> files >>> >> at >>> >> all is because we live in a file-based culture. And the reason our >>> >> culture >>> >> is so entrenched with files is because we are too heavily invested in >>> >> them, >>> >> and we aren't going to budge. *Files are about as low a storage >>> >> abstraction >>> >> as you can get*, and they pre-date even Unix. Yes, files belong in the >>> >> Stone >>> >> Age! >>> >> >>> >> >>> >> >>> >> kilon.alios wrote >>> >> > 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 < >>> >> >>> >> > btc@ >>> >> >>> >> > > wrote: >>> >> > >>> >> >> On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis < >>> >> >>> >> > kilon.alios@ >>> >> >>> >> > > >>> >> >> 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.alios@ >>> >> >>> >> > > >>> >> >> > 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. >>> >> >> >>> >> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> View this message in context: >>> >> >>> http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865820.html >>> >> Sent from the Pharo Smalltalk Users mailing list archive at >>> Nabble.com. >>> >> >>> >> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865872.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>>
