- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [COTDC] 35 - MCPackageCache

by laurent laffont

Aborted. Laurent On Thu, Mar 24, 2011 at 7:18 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Anyone or abort ? > > Laurent. > > On Wed, Mar 23, 2011 at 6:40 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> Today: MCPackageCache >> >> >> Comment Of The Day Contest - One Day One Comment >> Rules: >> #1: Each day a not commented class is elected. Each day the best comment >> will be integrated with name of the author(s). >> #2: If you cannot comment it, deprecate it. >> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> Laurent >> > >

March 24, 2011

Re: [Pharo-project] double click highlighting problem with quotation marks

by Nicolas Cellier

Of course, there is an ambiguity whether you want the closing quote or the opening parenthesis... And there is an arbitrary precedence rule. IMO, a modifier key might help to disambiguate... It would also be a nice thing to have a keyboard combination producing the same effect, For example: - Escape left_arrow selects downto the left opening, - Escape right_arrow selects upto the right closing... Unless of course there's already a shortcut I'm not aware of... Nicolas 2011/3/23 DougEdmunds <dougedmunds(a)gmail.com>: > Double clicking just to the left of a closing brace/bracket/parenthesis etc > normally > goes backwards, finds the opening brace/bracket/parenthesis and highlights > the material > between them. Â It does not work correctly if the character immediately > before the > closing mark is a single or double quotation mark. Â Instead it always goes > forward > from the quotation mark to try to find another quotation mark further in the > text. > > File ExampleClass.st > > 'From Pharo1.2 of 14 March 2011 [Latest update: #12341] on 23 March 2011 at > 11:16:26 am'! > Object subclass: #ExampleClass > Â Â Â Â instanceVariableNames: 'content owner' > Â Â Â Â classVariableNames: '' > Â Â Â Â poolDictionaries: '' > Â Â Â Â category: 'Sandbox'! > > !ExampleClass methodsFor: 'as yet unclassified' stamp: 'DougEdmunds > 3/23/2011 11:16'! > testMessage > > > Â Â Â Â | a b c d| > Â Â Â Â a := #( 1 2 (3 4 'test 1') 'test 2'). Â "click just before last closing > parens" > Â Â Â Â b := 'test 3'. > Â Â Â Â c := #( 1 2 (3 4 'test 4') 'test 5' ). "click just before last closing > parens" > Â Â Â Â d := 'test 6'. > ! ! > > -- > View this message in context: http://forum.world.st/double-click-highlighting-problem-with-quotation-mark… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

March 24, 2011

Re: [Pharo-project] Issue 3341 in pharo: use #= for integer comparison instead of #==

by pharo＠googlecode.com

Comment #4 on issue 3341 by nicolas....(a)gmail.com: use #= for integer comparison instead of #== http://code.google.com/p/pharo/issues/detail?id=3341 SLICE-Issue-3341-IntegerComparisonShallUseEqual-Part1-nice.1 Dependencies: Kernel-nice.847 Transform a few == into = and ~~ into ~= in Kernel

March 24, 2011

Re: [Pharo-project] custom code on squeaksource

by Eliot Miranda

On Thu, Mar 24, 2011 at 11:43 AM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > We are currently working on first-class slots and layouts in pharo. > This required some changes in how the class definitions are printed: > > ============================================= > Object subclass: #Layout > layout: ObjectLayout > slots: { > #host => Slot. > #compactClassIndex => Slot. > } > classSlots: {} > globals: '' > category: #'Slot-Layout' > I like it! A great use for tuples. Not sure I like sots vs instanceVarables, but then I'm an old man ;) Have you thought about automatically creating accessors for byte data? I'm imagining HeapField subclass: #ObjectHeaderLittleEndian type: #Bits fields: { #classTag => 20. #isPointers => 1 => #Boolean. #isIndexable => 1 => #Boolean. #slotSize => 8 => #Align => 8. #identityHash => 20 => #Align => 32. #isMarked => 1 => #Boolean. #isForwarded => 1 => #Boolean. #isWeak => 1 => #Boolean. #isEphemeron => 1 => #Boolean. } classSlots: {} globals: '' category: #'VMMaker-MemoryManager' > > ============================================= > > I adapted the MCClassDefinition >> definitionString to output our new class > definitions. > > However squeaksource is not too happy with this and rewrites it completely > using the default definition. > > Local mcz files contain the new definition, mcz files loaded form > squeaksources still the old definition. > > Is there a way to still use squeaksources with our custom classes? > > thanks > > v(^_^)v > camillo >

March 24, 2011

Re: [Pharo-project] test crashing the cog vm

by Eliot Miranda

On Thu, Mar 24, 2011 at 11:42 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 March 2011 19:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Tue, Mar 22, 2011 at 5:34 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> But why we could not have a byecode validator at the image level that > >> first make sure that byte code are in sync with the format of the > objects. > > > > Because it can be compromised. An in-image verifier is subject to > attack, > > and could be disabled by an attack that got past the in-image verifier > > before it got a chance to run. An in-VM verifier is not possible to > > side-step because it is the only way to execute code. So an in-VM > verifier > > can be secure but an in-image one can't and so is pointless. > > > For real hacker there's nothing impossible :) > True, but it can be much harder. How would you attempt to hack past the fact that the interpreter and JIT code, including the verifier, is in read-only memory? If this is the only route to create executable code, and it always verifies the bytecode before it executes then it is secure right? [there are issues; one doesn't want to verify a method each time it is activated in the interpreter, but e.g. a bit in the header saying "this method has been verified" might be easy to compromise. I'm not sure it is though, because one big advantage of the current funky method format (half literals, half btes) is that there's only one primitive to construct a method and it has to have a valid header, and there's only one way to modify the header, objectAt:put:. So as far as I can see the VM can in fact preserve the integrty a header flag bit that says "this method has been verified". Am I right or wrong?] > > Right now its not possible to split image to layered onion (like > operating system does, where you have kernel level, > and user level), but i think (at least in theory) such composition > could be implemented, except that sure thing > we don't have resources to invest in this direction. > > It is actually nice field for research (hello guys from academy :) > > -- > Best regards, > Igor Stasenko AKA sig. > >

March 24, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by Camillo Bruni

On 2011-03-24, at 15:00, Janko MivÅ¡ek wrote: > Let me think a bit towards very far vision, don't be angry on me .. :) > Here it is: > > - a common UI for both Pharo and the web, by extending Morphic ideas > to the web while things like CSS back to Morphic. that would be called Glamour and works already > - Morphic on top Jtalk for the web? The same API level one for Pharo > too? > - Isn't this like an extension, or better, towards the idea > behind Lively? > > Janko > > On 24. 03. 2011 09:17, StÃ©phane Ducasse wrote: >> Here is the vision: we need it better and simpler with better widgets, better UIBuilder and better tools. >> if you give me some engineers I can build something clear, now this is not the case so we are exploring and multiple paths >> Now if you want to see the system moving faster just join and help >> >> So here is a list >> >> Frameworks >> ---------- >> First step >> - Integrate polymorph (move class to the right packages, remove overrides) >> - Reduce complexity of morphic when possible >> >> In parallel >> - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) >> - Based on SimpleMorphic, clean also Morphic >> >> Alain told me that he want to take simpleMorphic and create a kernel that can be run and debugged on the side >> or morphic. Then he wants to add list and tree and see if he can add a better version of polymorph. >> Now he can fail too. so this is why the incremental points are important. >> >> Fixing and improving announcements is important >> - It was done during the last sprint >> - We were discussing how to make anonucement faster to avoid to climbing their parent tree - but no success so far. >> - We evaluated signals (as used in HPI frameworks) and we do not really like it. The use of thisContext is probably a problem among others. >> >> Widgets >> ------- >> We need better widgets >> - accordion >> - better text >> - grid >> We should evaluate your widgets to integrate them. But first we should clean what is there. >> Stacking on top of bad foundation just make the system more complex and difficult to maintain. >> >> >> Low level: a new Canvas and clean event >> ----------------------------------- >> Igor started to design a new canvas called Athens and we will see where it will go >> Again if people want to see this coming faster, they should help. >> The idea is to have a canvas for >> - opengl >> - cairo >> - bitbl >> >> We are evaluating the event hierarchy designed by Mickael Rueger and we would like >> to integrate it: eliminate the floating of arrays btween eventfetcher and HandMorph >> the idea is that event should be emitted by eventSensor not raw array >> >> I'm starting to clean Sensor references that are using the polling behavior because we should not have polling anymore >> the Windows virtual machine should be fixed and get the enhancement that Igor sent more than a year ago for the input semaphore >> and so that all the vm are aligned. >> >> >> Tools >> ----- >> We are rewriting from scratch the basic tools >> - Browser (Nautilus soon to be announced - with groups, package browsers, refactorings, may be plugin architecture) >> - Finder >> - TestRunner (soon) >> - MCBrowser >> - Debugger (waiting for a debugger model) >> The idea is that we want to kill the StringHolder hierarchy alltogther so in a first phase we will probably have to keep it >> for the debugger but only for it. >> >> We will remove toolBuilder (we are waiting to finish the TestRunner rewriting). >> >> Glamour will probably be used as a default super IDE of the future but it depends on people >> We are currently working on the fall back (the tools when you have nothing). >> >> So I hope it clarifies the picture and you are welcome to help. Now an important point >> This is not because something is under preparation that the other should not get clean and improve. >> We have no problem throwing away our effort if something better come up but we should be prepared that nothing come up or is delayed >> this is why we have this parallel strategy. >> >> >> Stef >> >> >> >> >> >> >> >> >>> Many new things is happens this days on Pharo, and I donÂ´t understand the >>> status of all. >>> >>> What is the future of GUI in Pharo? what changes will happen? which is the >>> roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will works >>> with another way of draw/render the morphs? >>> We will reduce the number of morph classes and hierarchy? The Morphic UI >>> designer will be incorporated in dev image? >>> >>> Thanks for your answers. >> >> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

March 24, 2011

[Pharo-project] custom code on squeaksource

by Camillo Bruni

We are currently working on first-class slots and layouts in pharo. This required some changes in how the class definitions are printed: ============================================= Object subclass: #Layout layout: ObjectLayout slots: { #host => Slot. #compactClassIndex => Slot. } classSlots: {} globals: '' category: #'Slot-Layout' ============================================= I adapted the MCClassDefinition >> definitionString to output our new class definitions. However squeaksource is not too happy with this and rewrites it completely using the default definition. Local mcz files contain the new definition, mcz files loaded form squeaksources still the old definition. Is there a way to still use squeaksources with our custom classes? thanks v(^_^)v camillo

March 24, 2011

Re: [Pharo-project] test crashing the cog vm

by Igor Stasenko

On 24 March 2011 19:34, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Mar 22, 2011 at 5:34 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> But why we could not have a byecode validator at the image level that >> first make sure that byte code are in sync with the format of the objects. > > Because it can be compromised. Â An in-image verifier is subject to attack, > and could be disabled by an attack that got past the in-image verifier > before it got a chance to run. Â An in-VM verifier is not possible to > side-step because it is the only way to execute code. Â So an in-VM verifier > can be secure but an in-image one can't and so is pointless. > For real hacker there's nothing impossible :) Right now its not possible to split image to layered onion (like operating system does, where you have kernel level, and user level), but i think (at least in theory) such composition could be implemented, except that sure thing we don't have resources to invest in this direction. It is actually nice field for research (hello guys from academy :) -- Best regards, Igor Stasenko AKA sig.

March 24, 2011

Re: [Pharo-project] test crashing the cog vm

by Eliot Miranda

On Tue, Mar 22, 2011 at 5:34 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > But why we could not have a byecode validator at the image level that first > make sure that byte code are in sync with the format of the objects. > Because it can be compromised. An in-image verifier is subject to attack, and could be disabled by an attack that got past the in-image verifier before it got a chance to run. An in-VM verifier is not possible to side-step because it is the only way to execute code. So an in-VM verifier can be secure but an in-image one can't and so is pointless. > Why this has to be done in the vm. > > Stef >

March 24, 2011

[Pharo-project] problem with obsolete classes in latest core

by Mariano Martinez Peck

It seems there is a problem with obsolete classes. SystemNavigation default obsoleteClasses -> an Array(AnObsoleteWordArray AnObsoletePath AnObsoleteLine) If you then browse WordArrayForSegment, you will see that it is a subclass from AnObsoleteWordArray. Changing that, back to WordArray, and then evaluating: Compiler recompileAll. Smalltalk fixObsoleteReferences. SystemNavigation default obsoleteClasses ->>> an Array(AnObsoleteWordArray) But I cannot get rid of that final obsoletClass. I tried inspecting SystemNavigation default obsoleteClasses and checking the pointers to the obsolete class, but I couldn't find anything. BTW, issue 3864 is failing because of that. cheers mariano

March 24, 2011