Re: [Pharo-project] how to change the default size of the Pharo host windows?
Locked
Re: [Pharo-project] how to change the default size of the Pharo host windows?
 
|
On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <[hidden email]> wrote: 2010/5/17 Eliot Miranda <[hidden email]>: SOme times it isn't appropriate to put flags in the special objects array. Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray. For all the flags which can be set in the header I provide access through vmParameterAt:[put:].
Ah, ok. That exists in vmParameterAt:[put:]. i.e. here's what's different in vmParameterAt:put: at Teleplace: VM parameters are numbered as follows:
... 4 allocationCount (read-only; nil in Cog VMs)
5 allocations between GCs (read-write; nil in Cog VMs) ...
41 imageFormatVersion for the VM 42 number of stack pages in use (Cog Stack VM only, otherwise nil)
43 desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil)
44 size of eden, in bytes (Cog VMs only, otherwise nil) 45 desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil)
46 size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil)
47 desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only)
48 various properties of the Cog VM as an integer encoding an array of bit flags. Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative)
Bit 1: if set, methods that are interpreted will have the flag bit set in their header Bit 2: if set, implies preempting a process does not put it to the back of its run queue
49-55 reserved for VM parameters that persist in the image (such as eden above) 56 number of process switches since startup (read-only)
57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only)
59 number of check event calls since startup (read-only) 60 number of stack page overflows since startup (read-only; Cog VMs only)
61 number of stack page divorces since startup (read-only; Cog VMs only) 62 compiled code compactions since startup (read-only; Cog only; otherwise nil)
63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)
|
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse <[hidden email]> wrote: cool we could turn them into nice query methods with semantics revealing names :) I would just use a SHaredPool with class variables appropriately named, e.g. SharedPool subclass: #VMParameterNames
instanceVariableNames: '' classVariableNames: '... ImageFormatVersion ...'
VMParameterNames class methods for initialization initialize ... ImageFormatVersion := 41
...then a client would use things like Smalltalk image vmParameterAt: ImageFormatVersion
These are for very special uses and I don't really like the idea of making access to them too easy.
|
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 18 May 2010 22:17, Eliot Miranda <[hidden email]> wrote: > > > > On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse <[hidden email]> wrote: >> >> cool we could turn them into nice query methods with semantics revealing names :) > > I would just use a SHaredPool with class variables appropriately named, e.g. > SharedPool subclass: #VMParameterNames > instanceVariableNames: '' > classVariableNames: '... ImageFormatVersion ...' > VMParameterNames class methods for initialization > initialize > ... > ImageFormatVersion := 41 > ... > then a client would use things like > Smalltalk image vmParameterAt: ImageFormatVersion > These are for very special uses and I don't really like the idea of making access to them too easy. > With such excuse, were ending up with a hacky shell scripts - an ultimately afwul way to access these attributes. It should be easier :) Its been always easy to make a mess: Array setFormat: 88888. Array new. bye-bye vm & image. Just give developers freedom, and then it is their own responsibility to not make mess out of it, not yours. -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 5/18/2010 1:36 PM, Igor Stasenko wrote: > With such excuse, were ending up with a hacky shell scripts - an > ultimately afwul way to access > these attributes. It should be easier :) > > Its been always easy to make a mess: > Array setFormat: 88888. > Array new. > bye-bye vm& image. > > Just give developers freedom, and then it is their own responsibility > to not make mess out of it, not yours. This isn't about "making a mess", it's about responsibilities. Currently, the VM and only the VM is responsible for handling the image file. This has several advantages because it allows some rather unsual 'file handling' on some platforms like Android (where there's not even an image file per se). Contrary to which, computing the class format is something that is within the responsibility of the image and not the VM. Of course, that could be changed - we could have some 'self-writing' and even 'self-reading' image code (the latter is a bit tricky, but not too much actually) that relieves the VM from having to ever read or write an image file, and that would be fine. But the point here is that the current distribution of responsibilities is such that the VM owns that part and it's got absolutely nothing to do with 'developers freedom' (you can after all change the VM!). Cheers, - Andreas |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 19 May 2010 00:31, Andreas Raab <[hidden email]> wrote: > > On 5/18/2010 1:36 PM, Igor Stasenko wrote: >> >> With such excuse, were ending up with a hacky shell scripts - an >> ultimately afwul way to access >> these attributes. It should be easier :) >> >> Its been always easy to make a mess: >> Array setFormat: 88888. >> Array new. >> bye-bye vm& image. >> >> Just give developers freedom, and then it is their own responsibility >> to not make mess out of it, not yours. > > This isn't about "making a mess", it's about responsibilities. Currently, > the VM and only the VM is responsible for handling the image file. This has > several advantages because it allows some rather unsual 'file handling' on > some platforms like Android (where there's not even an image file per se). > Contrary to which, computing the class format is something that is within > the responsibility of the image and not the VM. > > Of course, that could be changed - we could have some 'self-writing' and > even 'self-reading' image code (the latter is a bit tricky, but not too much > actually) that relieves the VM from having to ever read or write an image > file, and that would be fine. But the point here is that the current > distribution of responsibilities is such that the VM owns that part and it's > got absolutely nothing to do with 'developers freedom' (you can after all > change the VM!). > The problem, as i see it, that VM needs a set of startup options, either for bootstrapping interpreter's state or its modules, like display , network etc. So as VM evolves and develops, you may require some new options. And once you need that, a question arises: where you should put that, and who is responsible for initializing them etc etc.. so you adding a bunch of C code in addition to existing bloat. As i already repeated , multiple times, my vision is that VM should be stupid and primitive as much as possible. Whenever some operation requires some non-trivial logics, this should belong to a language side. In this way, i verifying all my ideas concerning changes to VM against this rule of thumb. If it doesn't pass that rule, then i doing things wrong. My point, that we should put these responsibilities up to language side: whether use display or not, what modules to load or not, what initial display size should be , etc etc. Then you having all levers of control at language side, and VM is basically serving your requests, unlike the current situation, when you often finding out, that there is no way how you could tell VM to use different option(s) , except from passing arguments from command line or altering an image file using hacky scripts. So, my point is to keep a bare minimum options in image header, while rest should use a uniform API, easy to use at both VM and language side. Then adding an extra option won't cause you much pain. Once you having an access to image file (or a bulk memory region), technically, there is no problem, where these options located, once you have a standartized way how to extract them. Saving an image with new set of options/header is merery a question of providing an additional argument to primitive, as simple as self snapshotPrimitive: options instead of self snapshotPrimitive I'm not saying that the above is best approach. But as i said, the better is one which makes VM less clever and more stupid, leaving the language side to decide what to do and when. > Cheers, > - Andreas > -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 5/18/2010 5:06 PM, Igor Stasenko wrote: > As i already repeated , multiple times, my vision is that VM should be > stupid and primitive as much as possible. And I have often pointed out that I do not share that vision. My idea of the VM is that it provides a safe abstraction layer in which it is hard to break anything so I can experiment freely and without fear of losing my valuable data. Since I'm not a language bigot, I don't mind dropping into C for the weird stuff. It actually suits me fine as a reminder that I'm entering unsafe grounds where I need to go slowly and carefully because even the most superficial error will crash me beyond a means of recovery. That's for example why I like JITs and why I like stuff like context-to-stack mapping; it provides a safe ground where I'm allowed to make mistakes without being unduly punished for a mere typo. > My point, that we should put these responsibilities up to language > side: whether use display or not, > what modules to load or not, what initial display size should be , etc etc. > Then you having all levers of control at language side, and VM is > basically serving your requests, unlike the current situation, > when you often finding out, that there is no way how you could > tell VM to use different option(s) , except from passing arguments > from command line or altering an image file using hacky scripts. There are ways of doing this properly. You can add the abstractions to the VM; it's not that the VM is not accessible. Your snapshot primitive is actually just such an abstraction - instead of reading and writing 'header bits' you are passing a set of options that the VM can interpret in any way it sees fit. That is an abstraction which still keeps the handling of the image file itself plainly in the VM - the VM can decide (for example) to store such options on Android in a completely different place than 'the image file'. Cheers, - Andreas |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 19 May 2010 03:40, Andreas Raab <[hidden email]> wrote: > > On 5/18/2010 5:06 PM, Igor Stasenko wrote: >> >> As i already repeated , multiple times, my vision is that VM should be >> stupid and primitive as much as possible. > > And I have often pointed out that I do not share that vision. > > My idea of the VM is that it provides a safe abstraction layer in which it > is hard to break anything so I can experiment freely and without fear of > losing my valuable data. Since I'm not a language bigot, I don't mind > dropping into C for the weird stuff. It actually suits me fine as a reminder > that I'm entering unsafe grounds where I need to go slowly and carefully > because even the most superficial error will crash me beyond a means of > recovery. That's for example why I like JITs and why I like stuff like > context-to-stack mapping; it provides a safe ground where I'm allowed to > make mistakes without being unduly punished for a mere typo. > Image having a lot of places which require you to be very careful: - bitblt & canvas code - morphic event handling - compiler & debugger - processes, semaphores etc - ... many many other places so, by following your logic, since its unsafe to alter the behavior in these places, then they should be moved to C code? A JIT is an exceptional example , mainly it is something, which you can't do without low-level access to machinery. What i don't like to happen is to see that eventually all smalltalk code consists from lines like: result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz andDontForgetAbout: zork andRideAPonyWith: that. >> My point, that we should put these responsibilities up to language >> side: whether use display or not, >> what modules to load or not, what initial display size should be , etc >> etc. >> Then you having all levers of control at language side, and VM is >> basically serving your requests, unlike the current situation, >> when you often finding out, that there is no way how you could >> tell VM to use different option(s) , except from passing arguments >> from command line or altering an image file using hacky scripts. > > There are ways of doing this properly. You can add the abstractions to the > VM; it's not that the VM is not accessible. Your snapshot primitive is > actually just such an abstraction - instead of reading and writing 'header > bits' you are passing a set of options that the VM can interpret in any way > it sees fit. That is an abstraction which still keeps the handling of the > image file itself plainly in the VM - the VM can decide (for example) to > store such options on Android in a completely different place than 'the > image file'. > > Cheers, > - Andreas > -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 5/18/2010 5:58 PM, Igor Stasenko wrote: > On 19 May 2010 03:40, Andreas Raab<[hidden email]> wrote: >> >> On 5/18/2010 5:06 PM, Igor Stasenko wrote: >>> >>> As i already repeated , multiple times, my vision is that VM should be >>> stupid and primitive as much as possible. >> >> And I have often pointed out that I do not share that vision. >> >> My idea of the VM is that it provides a safe abstraction layer in which it >> is hard to break anything so I can experiment freely and without fear of >> losing my valuable data. Since I'm not a language bigot, I don't mind >> dropping into C for the weird stuff. It actually suits me fine as a reminder >> that I'm entering unsafe grounds where I need to go slowly and carefully >> because even the most superficial error will crash me beyond a means of >> recovery. That's for example why I like JITs and why I like stuff like >> context-to-stack mapping; it provides a safe ground where I'm allowed to >> make mistakes without being unduly punished for a mere typo. >> > > Image having a lot of places which require you to be very careful: > - bitblt& canvas code > - morphic event handling > - compiler& debugger > - processes, semaphores etc > - ... many many other places > > so, by following your logic, since its unsafe to alter the behavior in > these places, then they should be moved to C code? Of course not. You can always program yourself into a corner where there's no way out. It's a matter of the expected failure mode. When I use the term 'safety' I mean mostly referential integrity. In other words memory safety. For example, the reason why I'm not in favor of advocating the use of the FFI instead of the use of plugins is that when using the FFI people do not understand what could go wrong because they don't understand the concepts of the underlying platform. However, when you write a plugin you're proving that at least you know how to use C and usually this means you know *something* about the related set of issues. And of course, when the very same people who have no clue about C and memory management corrupt their heap by the use of the FFI you get these complaints about how 'unstable' the system is. How very ironic. In any case, my definition of 'safety' is not the same you're implying above. It mostly relates to memory safety. BTW, many of the sticky points you're mentioning could be fixed by having a 'panic' button for the VM that simply suspends all processes and fires up a single new process to listen on a port and take commands. SSH into the image and you can see what you can repair. And yet again, it's the VM that provides the way out here because your in-image handling of the panic button could already be compromised. > What i don't like to happen is to see that eventually all smalltalk > code consists from lines like: > > result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz > andDontForgetAbout: zork andRideAPonyWith: that. That's called a 'glue' or 'scripting' language. Python is having dramatic success with effectively just that. Cheers, - Andreas |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 19 May 2010 04:38, Andreas Raab <[hidden email]> wrote: > > On 5/18/2010 5:58 PM, Igor Stasenko wrote: >> >> On 19 May 2010 03:40, Andreas Raab<[hidden email]> wrote: >>> >>> On 5/18/2010 5:06 PM, Igor Stasenko wrote: >>>> >>>> As i already repeated , multiple times, my vision is that VM should be >>>> stupid and primitive as much as possible. >>> >>> And I have often pointed out that I do not share that vision. >>> >>> My idea of the VM is that it provides a safe abstraction layer in which >>> it >>> is hard to break anything so I can experiment freely and without fear of >>> losing my valuable data. Since I'm not a language bigot, I don't mind >>> dropping into C for the weird stuff. It actually suits me fine as a >>> reminder >>> that I'm entering unsafe grounds where I need to go slowly and carefully >>> because even the most superficial error will crash me beyond a means of >>> recovery. That's for example why I like JITs and why I like stuff like >>> context-to-stack mapping; it provides a safe ground where I'm allowed to >>> make mistakes without being unduly punished for a mere typo. >>> >> >> Image having a lot of places which require you to be very careful: >> - bitblt& canvas code >> - morphic event handling >> - compiler& debugger >> - processes, semaphores etc >> - ... many many other places >> >> so, by following your logic, since its unsafe to alter the behavior in >> these places, then they should be moved to C code? > > Of course not. You can always program yourself into a corner where there's > no way out. It's a matter of the expected failure mode. When I use the term > 'safety' I mean mostly referential integrity. In other words memory safety. > > For example, the reason why I'm not in favor of advocating the use of the > FFI instead of the use of plugins is that when using the FFI people do not > understand what could go wrong because they don't understand the concepts of > the underlying platform. However, when you write a plugin you're proving > that at least you know how to use C and usually this means you know > *something* about the related set of issues. > > And of course, when the very same people who have no clue about C and memory > management corrupt their heap by the use of the FFI you get these complaints > about how 'unstable' the system is. How very ironic. > That's not ironic. That's plain stupid. If people using FFI, and don't realizing what is 'direct memory access', and all consequences of it, then you will simply waste your time arguing with them about 'safety', whatever meaning they putting in it. But i doubt you'll find such people. The point is, that there always should be a wrapping layer, written either in form of plugin or using FFI , which provides such safety. And i don't care, which language used to implement that - smalltalk or C. In both you have a very same chances to do stupid things and crash your system. Except that with FFI, you don't need to recompile plugin/VM each time you fixed the bug. > In any case, my definition of 'safety' is not the same you're implying > above. It mostly relates to memory safety. > > BTW, many of the sticky points you're mentioning could be fixed by having a > 'panic' button for the VM that simply suspends all processes and fires up a > single new process to listen on a port and take commands. SSH into the image > and you can see what you can repair. And yet again, it's the VM that > provides the way out here because your in-image handling of the panic button > could already be compromised. > Array setFormat: 88888. or Object become: nil. So, i'd rather focus on a such design, where direct manipulation with critical parts of environment is sufficiently guarded against fools, by using safety wrappers or multi-level capability-based mechanisms. >> What i don't like to happen is to see that eventually all smalltalk >> code consists from lines like: >> >> result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz >> andDontForgetAbout: zork andRideAPonyWith: that. > > That's called a 'glue' or 'scripting' language. Python is having dramatic > success with effectively just that. > Yeah.. scripting language is cool, when you having a host application, specialized in doing something good, and leaving a window of flexibility by providing scripting frontend. But VM is apparently wrong place for that. If you would ask me, how one could use smalltalk for scripting , then first thing, what we should do is to change VM to be a dynamically loadable library, with nice and consistent API. And, obviously, everything except interpreter should be separated from VM core. There should be no windowing, events, networking and many other things , which hardcoded by default in current VM. A host application should be able to easily provide own, in case of need. > Cheers, > - Andreas > -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
P.S. by any means, if we want squeak to serve as a tool for professionals, lets grow up and make VM for professionals, where they would be easily able to do things, without much fuss. But if we treat an interpreted language as a kinder-garden for childs, where they can do whatever they want with their toys, without nuking a planet, then they'll never grow up, because being grown up means taking responsibility for own actions, and no parental control, who could save you from your own mistakes and buy you a new toy. On 19 May 2010 05:41, Igor Stasenko <[hidden email]> wrote: > On 19 May 2010 04:38, Andreas Raab <[hidden email]> wrote: >> >> On 5/18/2010 5:58 PM, Igor Stasenko wrote: >>> >>> On 19 May 2010 03:40, Andreas Raab<[hidden email]> wrote: >>>> >>>> On 5/18/2010 5:06 PM, Igor Stasenko wrote: >>>>> >>>>> As i already repeated , multiple times, my vision is that VM should be >>>>> stupid and primitive as much as possible. >>>> >>>> And I have often pointed out that I do not share that vision. >>>> >>>> My idea of the VM is that it provides a safe abstraction layer in which >>>> it >>>> is hard to break anything so I can experiment freely and without fear of >>>> losing my valuable data. Since I'm not a language bigot, I don't mind >>>> dropping into C for the weird stuff. It actually suits me fine as a >>>> reminder >>>> that I'm entering unsafe grounds where I need to go slowly and carefully >>>> because even the most superficial error will crash me beyond a means of >>>> recovery. That's for example why I like JITs and why I like stuff like >>>> context-to-stack mapping; it provides a safe ground where I'm allowed to >>>> make mistakes without being unduly punished for a mere typo. >>>> >>> >>> Image having a lot of places which require you to be very careful: >>> - bitblt& canvas code >>> - morphic event handling >>> - compiler& debugger >>> - processes, semaphores etc >>> - ... many many other places >>> >>> so, by following your logic, since its unsafe to alter the behavior in >>> these places, then they should be moved to C code? >> >> Of course not. You can always program yourself into a corner where there's >> no way out. It's a matter of the expected failure mode. When I use the term >> 'safety' I mean mostly referential integrity. In other words memory safety. >> > ok. > >> For example, the reason why I'm not in favor of advocating the use of the >> FFI instead of the use of plugins is that when using the FFI people do not >> understand what could go wrong because they don't understand the concepts of >> the underlying platform. However, when you write a plugin you're proving >> that at least you know how to use C and usually this means you know >> *something* about the related set of issues. >> >> And of course, when the very same people who have no clue about C and memory >> management corrupt their heap by the use of the FFI you get these complaints >> about how 'unstable' the system is. How very ironic. >> > > That's not ironic. That's plain stupid. > If people using FFI, and don't realizing what is 'direct memory > access', and all consequences > of it, then you will simply waste your time arguing with them about > 'safety', whatever meaning they putting in it. > > But i doubt you'll find such people. The point is, that there always > should be a wrapping layer, > written either in form of plugin or using FFI , which provides such safety. > And i don't care, which language used to implement that - smalltalk or C. > In both you have a very same chances to do stupid things and crash your system. > Except that with FFI, you don't need to recompile plugin/VM each time > you fixed the bug. > >> In any case, my definition of 'safety' is not the same you're implying >> above. It mostly relates to memory safety. >> >> BTW, many of the sticky points you're mentioning could be fixed by having a >> 'panic' button for the VM that simply suspends all processes and fires up a >> single new process to listen on a port and take commands. SSH into the image >> and you can see what you can repair. And yet again, it's the VM that >> provides the way out here because your in-image handling of the panic button >> could already be compromised. >> > panic button won't help if you do > Array setFormat: 88888. or Object become: nil. > > So, i'd rather focus on a such design, where direct manipulation with > critical parts > of environment is sufficiently guarded against fools, by using safety > wrappers or > multi-level capability-based mechanisms. > >>> What i don't like to happen is to see that eventually all smalltalk >>> code consists from lines like: >>> >>> result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz >>> andDontForgetAbout: zork andRideAPonyWith: that. >> >> That's called a 'glue' or 'scripting' language. Python is having dramatic >> success with effectively just that. >> > Yeah.. scripting language is cool, when you having a host application, > specialized in doing something good, and leaving a window of > flexibility by providing scripting frontend. > But VM is apparently wrong place for that. > > If you would ask me, how one could use smalltalk for scripting , then > first thing, what we should do > is to change VM to be a dynamically loadable library, with nice and > consistent API. > And, obviously, everything except interpreter should be separated from VM core. > There should be no windowing, events, networking and many other things > , which hardcoded by default > in current VM. > A host application should be able to easily provide own, in case of need. > >> Cheers, >> - Andreas >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 5/18/2010 7:57 PM, Igor Stasenko wrote: > P.S. > by any means, if we want squeak to serve as a tool for professionals, > lets grow up and make VM for professionals, where they would be easily > able to do things, without much fuss. > But if we treat an interpreted language as a kinder-garden for childs, where > they can do whatever they want with their toys, without nuking a planet, > then they'll never grow up, because being grown up means taking > responsibility for own actions, > and no parental control, who could save you from your own mistakes and > buy you a new toy. Can we please disagree without this silly polemic? Cheers, - Andreas > On 19 May 2010 05:41, Igor Stasenko<[hidden email]> wrote: >> On 19 May 2010 04:38, Andreas Raab<[hidden email]> wrote: >>> >>> On 5/18/2010 5:58 PM, Igor Stasenko wrote: >>>> >>>> On 19 May 2010 03:40, Andreas Raab<[hidden email]> wrote: >>>>> >>>>> On 5/18/2010 5:06 PM, Igor Stasenko wrote: >>>>>> >>>>>> As i already repeated , multiple times, my vision is that VM should be >>>>>> stupid and primitive as much as possible. >>>>> >>>>> And I have often pointed out that I do not share that vision. >>>>> >>>>> My idea of the VM is that it provides a safe abstraction layer in which >>>>> it >>>>> is hard to break anything so I can experiment freely and without fear of >>>>> losing my valuable data. Since I'm not a language bigot, I don't mind >>>>> dropping into C for the weird stuff. It actually suits me fine as a >>>>> reminder >>>>> that I'm entering unsafe grounds where I need to go slowly and carefully >>>>> because even the most superficial error will crash me beyond a means of >>>>> recovery. That's for example why I like JITs and why I like stuff like >>>>> context-to-stack mapping; it provides a safe ground where I'm allowed to >>>>> make mistakes without being unduly punished for a mere typo. >>>>> >>>> >>>> Image having a lot of places which require you to be very careful: >>>> - bitblt& canvas code >>>> - morphic event handling >>>> - compiler& debugger >>>> - processes, semaphores etc >>>> - ... many many other places >>>> >>>> so, by following your logic, since its unsafe to alter the behavior in >>>> these places, then they should be moved to C code? >>> >>> Of course not. You can always program yourself into a corner where there's >>> no way out. It's a matter of the expected failure mode. When I use the term >>> 'safety' I mean mostly referential integrity. In other words memory safety. >>> >> ok. >> >>> For example, the reason why I'm not in favor of advocating the use of the >>> FFI instead of the use of plugins is that when using the FFI people do not >>> understand what could go wrong because they don't understand the concepts of >>> the underlying platform. However, when you write a plugin you're proving >>> that at least you know how to use C and usually this means you know >>> *something* about the related set of issues. >>> >>> And of course, when the very same people who have no clue about C and memory >>> management corrupt their heap by the use of the FFI you get these complaints >>> about how 'unstable' the system is. How very ironic. >>> >> >> That's not ironic. That's plain stupid. >> If people using FFI, and don't realizing what is 'direct memory >> access', and all consequences >> of it, then you will simply waste your time arguing with them about >> 'safety', whatever meaning they putting in it. >> >> But i doubt you'll find such people. The point is, that there always >> should be a wrapping layer, >> written either in form of plugin or using FFI , which provides such safety. >> And i don't care, which language used to implement that - smalltalk or C. >> In both you have a very same chances to do stupid things and crash your system. >> Except that with FFI, you don't need to recompile plugin/VM each time >> you fixed the bug. >> >>> In any case, my definition of 'safety' is not the same you're implying >>> above. It mostly relates to memory safety. >>> >>> BTW, many of the sticky points you're mentioning could be fixed by having a >>> 'panic' button for the VM that simply suspends all processes and fires up a >>> single new process to listen on a port and take commands. SSH into the image >>> and you can see what you can repair. And yet again, it's the VM that >>> provides the way out here because your in-image handling of the panic button >>> could already be compromised. >>> >> panic button won't help if you do >> Array setFormat: 88888. or Object become: nil. >> >> So, i'd rather focus on a such design, where direct manipulation with >> critical parts >> of environment is sufficiently guarded against fools, by using safety >> wrappers or >> multi-level capability-based mechanisms. >> >>>> What i don't like to happen is to see that eventually all smalltalk >>>> code consists from lines like: >>>> >>>> result := vm doThis: foo andThat: bar andMakeSureItSafeToDo: baz >>>> andDontForgetAbout: zork andRideAPonyWith: that. >>> >>> That's called a 'glue' or 'scripting' language. Python is having dramatic >>> success with effectively just that. >>> >> Yeah.. scripting language is cool, when you having a host application, >> specialized in doing something good, and leaving a window of >> flexibility by providing scripting frontend. >> But VM is apparently wrong place for that. >> >> If you would ask me, how one could use smalltalk for scripting , then >> first thing, what we should do >> is to change VM to be a dynamically loadable library, with nice and >> consistent API. >> And, obviously, everything except interpreter should be separated from VM core. >> There should be no windowing, events, networking and many other things >> , which hardcoded by default >> in current VM. >> A host application should be able to easily provide own, in case of need. >> >>> Cheers, >>> - Andreas >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
In reply to this post by Igor Stasenko
On 5/18/2010 7:41 PM, Igor Stasenko wrote: > On 19 May 2010 04:38, Andreas Raab<[hidden email]> wrote: >> And of course, when the very same people who have no clue about C and memory >> management corrupt their heap by the use of the FFI you get these complaints >> about how 'unstable' the system is. How very ironic. > > That's not ironic. That's plain stupid. > If people using FFI, and don't realizing what is 'direct memory > access', and all consequences > of it, then you will simply waste your time arguing with them about > 'safety', whatever meaning they putting in it. > > But i doubt you'll find such people. The point is, that there always > should be a wrapping layer, > written either in form of plugin or using FFI , which provides such safety. See, this is where you're wrong. These problems are never *that* simple. If the stuff just crashes it'd be trivial to find. It's like concurrency bugs - when they're outright broken they're usually broken in 'easy' ways. However, the problems often show in forms where the system crashes unreproducibly two days before ship date. And the only way to work through this stuff is by proving yourself that the problem can't be here or there and to narrow it down to a place where you have a chance to find it. To give an example, for a long time we had apparently random VM crashes due to using vertex arrays in OpenGL. The code was as simple as one could think; just pushing the gl[Vertex|Color|Normal]Pointers into the context and call glDrawArrays. We found that this would crash because (as the name implies) the state is 'client' state and the GL actually keeps a pointer to the data. So if the operations would be interrupted by a process switch, if that process would cause a (full) GC, and if that GC would collect enough data to free that memory region, then and only then it would crash. This is how these problems show; there's nothing outright 'stupid' about it. BTW, the solution: Moving the entire operation into a plugin so that all of it is atomic. >> In any case, my definition of 'safety' is not the same you're implying >> above. It mostly relates to memory safety. >> >> BTW, many of the sticky points you're mentioning could be fixed by having a >> 'panic' button for the VM that simply suspends all processes and fires up a >> single new process to listen on a port and take commands. SSH into the image >> and you can see what you can repair. And yet again, it's the VM that >> provides the way out here because your in-image handling of the panic button >> could already be compromised. >> > panic button won't help if you do > Array setFormat: 88888. or Object become: nil. Sure. I never said there'd be perfect safety. There's no such thing. But that doesn't mean you shouldn't try to improve things. And a panic button could make many situations much less problematic than they are today. But the point here really is that by having the VM, instead of the image, do that, you get a level of indirection that can help fixing the broken parts. > So, i'd rather focus on a such design, where direct manipulation with > critical parts > of environment is sufficiently guarded against fools, by using safety > wrappers or > multi-level capability-based mechanisms. If you know how to use that to ensure that you're not dereferencing an invalid pointer I'm all ears. Seriously. If there's a safe way to use that stuff I'd love to use it. I should also point out that there *are* ways to do that safely. It depends on whether the thing you're talking to is memory safe or not. In our products we ship a Python bridge where you talk from Squeak to Python and back. That bridge is safe and I have no problems exposing it because it's objects on either end. You never get your hands on a 'pointer' you only get our hands on a Python object in Squeak or a Squeak object in Python that you can send messages to. Since Python is GCed as well the bridge comes down to a bit of mapping between Squeak and Python objects and after that's it's a complete and open free-for-all (incl. callbacks, error propagation and more). I'm completely game for a similar bridge to Java or .NET or any other memory safe object system. It's that memory unsafe stuff that I object to. > If you would ask me, how one could use smalltalk for scripting , then > first thing, what we should do > is to change VM to be a dynamically loadable library, with nice and > consistent API. Yes, indeed. When I wrote the bridge it was quite an eye opener. Both sides provide the same basic stuff, but what a difference in the interface! Clearly, the Python folks designed theirs to be used from C/C++ and clearly, we didn't ;-) Cheers, - Andreas |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
On 19 May 2010 07:16, Andreas Raab <[hidden email]> wrote: > > On 5/18/2010 7:41 PM, Igor Stasenko wrote: >> >> On 19 May 2010 04:38, Andreas Raab<[hidden email]> wrote: >>> >>> And of course, when the very same people who have no clue about C and >>> memory >>> management corrupt their heap by the use of the FFI you get these >>> complaints >>> about how 'unstable' the system is. How very ironic. >> >> That's not ironic. That's plain stupid. >> If people using FFI, and don't realizing what is 'direct memory >> access', and all consequences >> of it, then you will simply waste your time arguing with them about >> 'safety', whatever meaning they putting in it. >> >> But i doubt you'll find such people. The point is, that there always >> should be a wrapping layer, >> written either in form of plugin or using FFI , which provides such >> safety. > > See, this is where you're wrong. These problems are never *that* simple. If > the stuff just crashes it'd be trivial to find. It's like concurrency bugs - > when they're outright broken they're usually broken in 'easy' ways. However, > the problems often show in forms where the system crashes unreproducibly two > days before ship date. And the only way to work through this stuff is by > proving yourself that the problem can't be here or there and to narrow it > down to a place where you have a chance to find it. > > To give an example, for a long time we had apparently random VM crashes due > to using vertex arrays in OpenGL. The code was as simple as one could think; > just pushing the gl[Vertex|Color|Normal]Pointers into the context and call > glDrawArrays. We found that this would crash because (as the name implies) > the state is 'client' state and the GL actually keeps a pointer to the data. > So if the operations would be interrupted by a process switch, if that > process would cause a (full) GC, and if that GC would collect enough data to > free that memory region, then and only then it would crash. This is how > these problems show; there's nothing outright 'stupid' about it. BTW, the > solution: Moving the entire operation into a plugin so that all of it is > atomic. > i see. Its because you can't make a multiple FFI calls in a row primitively(atomically). And whenever you doing this using multiple sends, there's always a chance to interrupt it and this is where GC comes in play. :) Good example. But you could meet with same problem, if you would blindly implement separate gl[Vertex|Color|Normal]Pointers and glDrawArrays primitives, instead of a single glDrawArrays: vertexBufer colors: colorBuffer normals: normalBuffer attibs: attribBuffer ... And i don't think that going into VM you are automatically free from such mistakes. With NB, i could implement such primitive in image. And this is where enabling even more 'unsafety' would bring you more safety in the end :) Because when you know clearly, what you should do (safely), you will do it anyways, no matter what it takes. But then difference lies in other plane: how much effort and time it takes to implement it and integrate it into your application. I implemented multiple VM plugins, over a time, and i wouldn't say that i happy with this process. You have to (re)build VM each time, then you have to make sure that interfaces match between image side code and plugin, and then you have to guess , what go wrong if your prim fails.. so, its a whole adventure for brave & dedicated people. Shipping your code is next story: - ahh.. so, you made VM modifications? Bummer. - Get back when you have your changes integrated for all platforms & available in standard VM package. >>> In any case, my definition of 'safety' is not the same you're implying >>> above. It mostly relates to memory safety. >>> >>> BTW, many of the sticky points you're mentioning could be fixed by having >>> a >>> 'panic' button for the VM that simply suspends all processes and fires up >>> a >>> single new process to listen on a port and take commands. SSH into the >>> image >>> and you can see what you can repair. And yet again, it's the VM that >>> provides the way out here because your in-image handling of the panic >>> button >>> could already be compromised. >>> >> panic button won't help if you do >> Array setFormat: 88888. or Object become: nil. > > Sure. I never said there'd be perfect safety. There's no such thing. But > that doesn't mean you shouldn't try to improve things. And a panic button > could make many situations much less problematic than they are today. But > the point here really is that by having the VM, instead of the image, do > that, you get a level of indirection that can help fixing the broken parts. > >> So, i'd rather focus on a such design, where direct manipulation with >> critical parts >> of environment is sufficiently guarded against fools, by using safety >> wrappers or >> multi-level capability-based mechanisms. > > If you know how to use that to ensure that you're not dereferencing an > invalid pointer I'm all ears. Seriously. If there's a safe way to use that > stuff I'd love to use it. On windoze you could check if read/write at given memory region would cause GP fault. But checking that will cost you additional cycles, of course. Insted of that, i think its better to use structured exception handlers, so, you can catch GP faults and return into image as prim failure. > > I should also point out that there *are* ways to do that safely. It depends > on whether the thing you're talking to is memory safe or not. In our > products we ship a Python bridge where you talk from Squeak to Python and > back. That bridge is safe and I have no problems exposing it because it's > objects on either end. You never get your hands on a 'pointer' you only get > our hands on a Python object in Squeak or a Squeak object in Python that you > can send messages to. Since Python is GCed as well the bridge comes down to > a bit of mapping between Squeak and Python objects and after that's it's a > complete and open free-for-all (incl. callbacks, error propagation and > more). > > I'm completely game for a similar bridge to Java or .NET or any other memory > safe object system. It's that memory unsafe stuff that I object to. > Yeah, but unfortunately, C world is still there, behind the cover of all such 'memory safety' :) Not to mention, that there a tons of different libraries having no 'objects', but a raw C interfaces with all these raw pointers and such... But, again, once you need an access to some exact foreign interface the safety is on second plane, because first problem you need to solve is: how fast you could integrate it, how much time will pass between starting it, and running a first piece of code, which does what you need. Only then, you can start testing and working on the safety measures. So, i would say, that the faster you can fail (which means you already in testing stage), the better. :) >> If you would ask me, how one could use smalltalk for scripting , then >> first thing, what we should do >> is to change VM to be a dynamically loadable library, with nice and >> consistent API. > > Yes, indeed. When I wrote the bridge it was quite an eye opener. Both sides > provide the same basic stuff, but what a difference in the interface! > Clearly, the Python folks designed theirs to be used from C/C++ and clearly, > we didn't ;-) > > Cheers, > - Andreas > -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] how to change the default size of the Pharo host windows?
|
|
In reply to this post by Andreas.Raab
first thanks for the discussion it was really interesting. >>> If you would ask me, how one could use smalltalk for scripting , then >> first thing, what we should do >> is to change VM to be a dynamically loadable library, with nice and >> consistent API. > > Yes, indeed. When I wrote the bridge it was quite an eye opener. Both sides provide the same basic stuff, but what a difference in the interface! Clearly, the Python folks designed theirs to be used from C/C++ and clearly, we didn't ;-) Andreas do you see a chance that the vm slowly moves in that direction because this is an important point for the future. When I see lua getting embedded in a lot of cool app. Stef |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |