From juan at jvuletich.org Tue Oct 6 07:24:48 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Tue, 06 Oct 2015 09:24:48 -0300 Subject: [Cuis] Class Comment Browser In-Reply-To: <560C57DC.32345.163B7FF@dnorton.mindspring.com> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <4f00e132cd45e6e377ff945fafa610b0.squirrel@gator3294.hostgator.com> <560C57DC.32345.163B7FF@dnorton.mindspring.com> Message-ID: <5613BD90.4040204@jvuletich.org> Hi Dan, Apologies for the long delay in answering. I think you mean the text styler, that colorizes Smalltalk code, right? Well, an instance of InnerTextMorph might have a subinstance of SHTextStyler in the 'styler' variable. This is "Shout", originally from Squeak. But it might be disabled sometimes, as when the code pane is showing diffs, or bytecodes, etc. See #okToStyle , where the model is asked whether it is appropriate to style each time. If you can't solve the problem, point me to the latest version of CCB, and briefly describe steps, expected behavior, unwanted behavior (to be sure I understand), and I'll take a look. Cheers, Juan Vuletich On 30/09/2015 06:45 p.m., Dan Norton wrote: > Hi Juan, > > The editor class seems to remain constant as SmalltalkEditor. To see what is puzzling: > > open a browser on a class with an actual comment > view the class comment (? button) > select all of the comment and copy it > select, then deselect a message category > paste the comment in the code window as if defining a new method > see the difference in presentation > > What is making this switch? If I knew where this is done I might get the behavior I want in > CCB. > > - Dan > > On 30 Sep 2015 at 8:19, Juan Vuletich wrote: > >> Hi Dan, >> >> See the TextEditor hierarchy. See #editorClass, senders and >> implementors. >> It is the model who decides what kind of editor to use. >> >> An easy way to find out about this, is to realiza that what you want >> is >> the "Smalltalk Options" menu in code panes. Just write "Smalltalk >> Options" >> in some code pane, select it (without the quotes) and do right click >> / >> Smalltalk Options / Method Source with it. That leads you right to >> SmalltalkEditor. >> >> Cheers, >> Juan Vuletich >> >> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: >>> Hi Juan, >>> >>> >>> A little help, please. BrowserWindow uses >>> CodeWindow>>buildMorphicCodePane for the >>> class comment area. Although this area looks like text, >> expressions >>> appearing in class comments can be executed as in a workspace. >>> >>> I want the same behavior in Class Comment Browser, but all I get >> is text >>> behavior (no execution). How can this be changed? >>> >>> - Dan >>> >>> >>> _______________________________________________ >>> Cuis mailing list >>> Cuis at jvuletich.org >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >> >> _______________________________________________ >> Cuis mailing list >> Cuis at jvuletich.org >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From dnorton at mindspring.com Tue Oct 6 20:17:11 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 06 Oct 2015 21:17:11 -0400 Subject: [Cuis] Class Comment Browser In-Reply-To: <5613BD90.4040204@jvuletich.org> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <560C57DC.32345.163B7FF@dnorton.mindspring.com>, <5613BD90.4040204@jvuletich.org> Message-ID: <56147297.21959.20BF33E@dnorton.mindspring.com> Hi Juan, Delay? What delay? Not to worry :-) I regret that this problem is either beyond me or I'm blind to it. Had to clean up the act a bit because of all the fruitless experiments but the repo seems to behave OK. It is strongly desired by the (huge?) user community that the pane containing the comment would behave like a work space, e.g. allow statements to be executed and names to be highlighted and used to open a browser. The repo is: https://github.com/dhnorton/Cuis-Smalltalk-comments Please let me know what I need to do. - Dan On 6 Oct 2015 at 9:24, Juan Vuletich wrote: > Hi Dan, > > Apologies for the long delay in answering. > > I think you mean the text styler, that colorizes Smalltalk code, > right? > Well, an instance of InnerTextMorph might have a subinstance of > SHTextStyler in the 'styler' variable. This is "Shout", originally > from > Squeak. But it might be disabled sometimes, as when the code pane is > showing diffs, or bytecodes, etc. See #okToStyle , where the model > is > asked whether it is appropriate to style each time. > > If you can't solve the problem, point me to the latest version of > CCB, > and briefly describe steps, expected behavior, unwanted behavior (to > be > sure I understand), and I'll take a look. > > Cheers, > Juan Vuletich > > On 30/09/2015 06:45 p.m., Dan Norton wrote: > > Hi Juan, > > > > The editor class seems to remain constant as SmalltalkEditor. To > see what is puzzling: > > > > open a browser on a class with an actual comment > > view the class comment (? button) > > select all of the comment and copy it > > select, then deselect a message category > > paste the comment in the code window as if defining a new > method > > see the difference in presentation > > > > What is making this switch? If I knew where this is done I might > get the behavior I want in > > CCB. > > > > - Dan > > > > On 30 Sep 2015 at 8:19, Juan Vuletich wrote: > > > >> Hi Dan, > >> > >> See the TextEditor hierarchy. See #editorClass, senders and > >> implementors. > >> It is the model who decides what kind of editor to use. > >> > >> An easy way to find out about this, is to realiza that what you > want > >> is > >> the "Smalltalk Options" menu in code panes. Just write > "Smalltalk > >> Options" > >> in some code pane, select it (without the quotes) and do right > click > >> / > >> Smalltalk Options / Method Source with it. That leads you right > to > >> SmalltalkEditor. > >> > >> Cheers, > >> Juan Vuletich > >> > >> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: > >>> Hi Juan, > >>> > >>> > >>> A little help, please. BrowserWindow uses > >>> CodeWindow>>buildMorphicCodePane for the > >>> class comment area. Although this area looks like text, > >> expressions > >>> appearing in class comments can be executed as in a workspace. > >>> > >>> I want the same behavior in Class Comment Browser, but all I > get > >> is text > >>> behavior (no execution). How can this be changed? > >>> > >>> - Dan > >>> > >>> > >>> _______________________________________________ > >>> Cuis mailing list > >>> Cuis at jvuletich.org > >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > >>> > >>> > >> > >> _______________________________________________ > >> Cuis mailing list > >> Cuis at jvuletich.org > >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > > _______________________________________________ > > Cuis mailing list > > Cuis at jvuletich.org > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > From juan at jvuletich.org Wed Oct 7 07:17:40 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 7 Oct 2015 09:17:40 -0300 Subject: [Cuis] Class Comment Browser In-Reply-To: <56147297.21959.20BF33E@dnorton.mindspring.com> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <560C57DC.32345.163B7FF@dnorton.mindspring.com>, <5613BD90.4040204@jvuletich.org> <56147297.21959.20BF33E@dnorton.mindspring.com> Message-ID: <4f40bf8bef60787638764dcb4d9f9a20.squirrel@gator3294.hostgator.com> Hi Dan, If you inspect the InnerTextMorph in your right pane, it has: editor: aTextEditor styler: nil To be able to evaluate code, you need a SmalltalkEditor. This does the trick: CommentGuide >> editorClassFor: textGetter ^SmalltalkEditor If you also want Workspace like syntax highlighting, you need a TextStyler. Add: CommentGuide >> textStylerClassFor: textGetter ^SHTextStylerST80 CommentGuide >> shoutAboutToStyle: aSHTextStyler ^true Keep in mind that most class comments can not be parsed as code! That's why in the regular browser, methods are syntaxHighlighted, but class comments are not. I feel that with the hints I gave you before, you could have found out all this yourself. You will get the most out of Smalltalk if you use the code inspection tools as much as possible, and you are not afraid of exploring, experimenting, and trying to learn how the system works. Cheers, Juan Vuletich On Tue, October 6, 2015 10:17 pm, Dan Norton wrote: > Hi Juan, > > > Delay? What delay? Not to worry :-) I regret that this problem is either > beyond me or I'm blind to it. > > Had to clean up the act a bit because of all the fruitless experiments > but the repo seems to behave OK. It is strongly desired by the (huge?) > user community that the pane containing the comment would behave like a > work space, e.g. allow statements to be executed and names to be > highlighted and used to open a browser. The repo is: > > https://github.com/dhnorton/Cuis-Smalltalk-comments > > > Please let me know what I need to do. > > > - Dan > > > On 6 Oct 2015 at 9:24, Juan Vuletich wrote: > > >> Hi Dan, >> >> >> Apologies for the long delay in answering. >> >> >> I think you mean the text styler, that colorizes Smalltalk code, >> right? Well, an instance of InnerTextMorph might have a subinstance of >> SHTextStyler in the 'styler' variable. This is "Shout", originally >> from Squeak. But it might be disabled sometimes, as when the code pane is >> showing diffs, or bytecodes, etc. See #okToStyle , where the model is >> asked whether it is appropriate to style each time. >> >> If you can't solve the problem, point me to the latest version of >> CCB, >> and briefly describe steps, expected behavior, unwanted behavior (to be >> sure I understand), and I'll take a look. >> >> Cheers, >> Juan Vuletich >> >> >> On 30/09/2015 06:45 p.m., Dan Norton wrote: >> >>> Hi Juan, >>> >>> >>> The editor class seems to remain constant as SmalltalkEditor. To >>> >> see what is puzzling: >>> >>> open a browser on a class with an actual comment view the class >>> comment (? button) select all of the comment and copy it select, then >>> deselect a message category paste the comment in the code window as if >>> defining a new >> method >>> see the difference in presentation >>> >>> What is making this switch? If I knew where this is done I might >>> >> get the behavior I want in >>> CCB. >>> >>> >>> - Dan >>> >>> >>> On 30 Sep 2015 at 8:19, Juan Vuletich wrote: >>> >>> >>>> Hi Dan, >>>> >>>> >>>> See the TextEditor hierarchy. See #editorClass, senders and >>>> implementors. It is the model who decides what kind of editor to use. >>>> >>>> >>>> An easy way to find out about this, is to realiza that what you >>>> >> want >>>> is the "Smalltalk Options" menu in code panes. Just write >> "Smalltalk >> >>>> Options" >>>> in some code pane, select it (without the quotes) and do right >> click >>>> / >>>> Smalltalk Options / Method Source with it. That leads you right >>>> >> to >>>> SmalltalkEditor. >>>> >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> >>>> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: >>>> >>>>> Hi Juan, >>>>> >>>>> >>>>> >>>>> A little help, please. BrowserWindow uses >>>>> CodeWindow>>buildMorphicCodePane for the >>>>> class comment area. Although this area looks like text, >>>> expressions >>>>> appearing in class comments can be executed as in a workspace. >>>>> >>>>> I want the same behavior in Class Comment Browser, but all I >>>>> >> get >>>> is text >>>>> behavior (no execution). How can this be changed? >>>>> >>>>> - Dan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Cuis mailing list >>>>> Cuis at jvuletich.org >>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Cuis mailing list >>>> Cuis at jvuletich.org >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>> >>> >>> >>> _______________________________________________ >>> Cuis mailing list >>> Cuis at jvuletich.org >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >> > > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > From Ken.Dickey at Whidbey.com Mon Oct 12 10:05:16 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Mon, 12 Oct 2015 08:05:16 -0700 Subject: [Cuis] veryShortName Message-ID: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Greetings, I have been looking at FileMan and had some confusion with #FmFileEntry>>shortName. 'this.that.txt' asFileEntry name. ==> 'this.that.txt' 'this.that.txt' asFileEntry shortName. ==> 'this' I expected #shortName to answer the same result as baseName. 'this.that.txt' asFileEntry baseName. ==> 'this.that' I find the current behavior confusing. Is there a real need to have #shortName differ from #baseName? If the current #shortName behavior is required, could the name be changed to something nore mnemonic. Perhaps #firstPrefix ? Thanks much, -KenD -- KenD From ume at blueplane.jp Sat Oct 17 00:28:23 2015 From: ume at blueplane.jp (Masashi UMEZAWA) Date: Sat, 17 Oct 2015 14:28:23 +0900 Subject: [Cuis] veryShortName In-Reply-To: <20151012080516.9224a7578af856399be5679f@Whidbey.com> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Message-ID: Hi all, Actually I sometimes uses #shortName for selecting package name part from MCZ files (package.123.mcz). In this case, package name part is not prefix. But #shortName is not so clear, neither. Perhaps #firstName or #nameUpToDot would be better? Best regards, 2015-10-13 0:05 GMT+09:00 KenD : > Greetings, > > I have been looking at FileMan and had some confusion with #FmFileEntry>>shortName. > > 'this.that.txt' asFileEntry name. ==> 'this.that.txt' > 'this.that.txt' asFileEntry shortName. ==> 'this' > > I expected #shortName to answer the same result as baseName. > > 'this.that.txt' asFileEntry baseName. ==> 'this.that' > > I find the current behavior confusing. Is there a real need to have #shortName differ from #baseName? > > If the current #shortName behavior is required, could the name be changed to something nore mnemonic. Perhaps #firstPrefix ? > > Thanks much, > -KenD > > > > > -- > KenD -- [:masashi | ^umezawa] From Ken.Dickey at Whidbey.com Sat Oct 17 09:39:32 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sat, 17 Oct 2015 07:39:32 -0700 Subject: [Cuis] veryShortName In-Reply-To: References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Message-ID: <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> On Sat, 17 Oct 2015 14:28:23 +0900 Masashi UMEZAWA wrote: > Perhaps #firstName or #nameUpToDot would be better? Yes. Either works for me. Thanks, KenD From dnorton at mindspring.com Tue Oct 20 15:43:02 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 20 Oct 2015 16:43:02 -0400 Subject: [Cuis] PluggableListMorph Message-ID: <5626A756.25587.11E39F9@dnorton.mindspring.com> Greetings, PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be daunting because of the use of the dependency mechanism. AFAICT the tools do not display dependencies and even if they did, it's not clear why some of them exist. What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar that can be in the Terse Guide. It should show an example of selection in one list causing the population of another list and selection in that list causing the population of some other morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a method sends #changed: with a parameter referring to another method - why? The design needs to be explained. - Dan From Ken.Dickey at Whidbey.com Thu Oct 22 17:39:04 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Thu, 22 Oct 2015 15:39:04 -0700 Subject: [Cuis] PluggableListMorph In-Reply-To: <5626A756.25587.11E39F9@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com> Message-ID: <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> On Tue, 20 Oct 2015 16:43:02 -0400 "Dan Norton" wrote: > PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be > daunting because of the use of the dependency mechanism. AFAICT the tools do not display > dependencies and even if they did, it's not clear why some of them exist. > > What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar > that can be in the Terse Guide. It should show an example of selection in one list causing the > population of another list and selection in that list causing the population of some other > morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a > method sends #changed: with a parameter referring to another method - why? The design > needs to be explained. Dan, +1 A tool to detect/show such "out of band" control/change linkages/dependencies would be most welcomed, as would a Principles of Operation. Taking a quick look at my own code ("guilty as charged, sir") >> grep "changed:" */*.st Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! ! Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #actualContents! ! Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. I see two cases where one wants to be notified of changes without adding specific code to individual morph instances. In each case one wants to propagate updates to dependent views. [1] Change in internal Morph state should update viewers onto that state. [2] The special case of selection change in a list (PlugableListMorph) should update dependent viewers. So the simple explanation for "WHY change notification" is to update (perhaps multiple) viewers without doing special notification code in the Morphs being viewed. The target Morph should not have to know how many, if any, views onto its state exist. HOW is the registration process: Class ActiveModel and its subclass: SystemChangeNotifier I am a rare user of the change notification mechanism and would also benefit from good documentation and better tool(s) in this area. Cheers, KenD From dnorton at mindspring.com Fri Oct 23 10:56:26 2015 From: dnorton at mindspring.com (Dan Norton) Date: Fri, 23 Oct 2015 11:56:26 -0400 Subject: [Cuis] PluggableListMorph In-Reply-To: <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> Message-ID: <562A58AA.15972.4E08E7@dnorton.mindspring.com> On 22 Oct 2015 at 15:39, KenD wrote: > On Tue, 20 Oct 2015 16:43:02 -0400 > "Dan Norton" wrote: > > > PluggableListMorph has valuable behavior but applying it in morphs > with multiple lists can be > > daunting because of the use of the dependency mechanism. AFAICT > the tools do not display > > dependencies and even if they did, it's not clear why some of them > exist. > > > > What is needed is a "PluggableListMorph Principles of Operation" > doc, or something similar > > that can be in the Terse Guide. It should show an example of > selection in one list causing the > > population of another list and selection in that list causing the > population of some other > > morph. Isn't that like FileList? Yes, but we need the whys and > wherefors. For example, a > > method sends #changed: with a parameter referring to another > method - why? The design > > needs to be explained. > > Dan, > > +1 > > A tool to detect/show such "out of band" control/change > linkages/dependencies would be most welcomed, as would a Principles > of Operation. > > Taking a quick look at my own code ("guilty as charged, sir") > > >> grep "changed:" */*.st > Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph > Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! > ! > Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. > Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > #actualContents! ! > Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. > Hi Ken, In #actualContents: there is "self changed: #actualContents" which seems reasonable. However, in #refetch there is "self changed: #refetch" which is perplexing because it looks like infinite recursion, but it must be OK because similar examples appear in Browser. - Dan From juan at jvuletich.org Fri Oct 23 11:31:51 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 13:31:51 -0300 Subject: [Cuis] PluggableListMorph In-Reply-To: <5626A756.25587.11E39F9@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com> Message-ID: <562A60F7.1070702@jvuletich.org> Hi Dan, On 20/10/2015 05:43 p.m., Dan Norton wrote: > Greetings, > > PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be > daunting because of the use of the dependency mechanism. AFAICT the tools do not display > dependencies and even if they did, it's not clear why some of them exist. Yes. Most tools are still using the changed:/update: dependency mechanism that comes from MVC in Smalltalk-80. Later, Squeak and Cuis also included the #when:send:to: event system. It should replace changed:/update: in all client code because it helps produce code that is easier to understand. This is something we should do at some moment. > What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar > that can be in the Terse Guide. It should show an example of selection in one list causing the > population of another list and selection in that list causing the population of some other > morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a > method sends #changed: with a parameter referring to another method - why? The design > needs to be explained. > > - Dan Most likely all the classic references apply (In the blue book? Or most likely in Inside Smalltalk vol II). I'm sure there are others. Including excepts and/or references to them in TerseGuide would indeed be great. Please also keep in mind that this is not only for lists. It is essentially the same mechanism used for text panes, buttons, lists, tree lists, etc. Thanks, Juan Vuletich From juan at jvuletich.org Fri Oct 23 11:59:43 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 13:59:43 -0300 Subject: [Cuis] PluggableListMorph In-Reply-To: <562A58AA.15972.4E08E7@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> <562A58AA.15972.4E08E7@dnorton.mindspring.com> Message-ID: <562A677F.50500@jvuletich.org> On 23/10/2015 12:56 p.m., Dan Norton wrote: > On 22 Oct 2015 at 15:39, KenD wrote: > >> On Tue, 20 Oct 2015 16:43:02 -0400 >> "Dan Norton" wrote: >> >>> PluggableListMorph has valuable behavior but applying it in morphs >> with multiple lists can be >>> daunting because of the use of the dependency mechanism. AFAICT >> the tools do not display >>> dependencies and even if they did, it's not clear why some of them >> exist. >>> What is needed is a "PluggableListMorph Principles of Operation" >> doc, or something similar >>> that can be in the Terse Guide. It should show an example of >> selection in one list causing the >>> population of another list and selection in that list causing the >> population of some other >>> morph. Isn't that like FileList? Yes, but we need the whys and >> wherefors. For example, a >>> method sends #changed: with a parameter referring to another >> method - why? The design >>> needs to be explained. >> Dan, >> >> +1 >> >> A tool to detect/show such "out of band" control/change >> linkages/dependencies would be most welcomed, as would a Principles >> of Operation. >> >> Taking a quick look at my own code ("guilty as charged, sir") >> >>>> grep "changed:" */*.st >> Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! >> ! >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: >> #actualContents! ! >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. >> > Hi Ken, > > In #actualContents: there is "self changed: #actualContents" which seems reasonable. > > However, in #refetch there is "self changed: #refetch" which is perplexing because it looks > like infinite recursion, but it must be OK because similar examples appear in Browser. > > - Dan Just look at senders of #refetched . (not refetch!) It is quite simple, actually. To see a bit more on how lists are used, see references to PluggableListMorph. The second is #buildMorphicMessageCatList. See how it parametrizes the instance it builds. These methods that create various lists are quite similar, and all they do is to bind each list with a different aspect of the model. In this case, with #messageCategoryList. See implementors and senders. It is clear that the implementors are methods in models that answer (guess what!!!!) a list of message categories. When you look at senders senders, you can see that some are in the model, doing things like 'self changed: #messageCategoryList'. It is easy to see that this means that the list of message categories have changed, and anybody depending on that should update itself. Now we have a detail that is not that obvious, and most likely the clue you need to understand this all. See implementors of #update: in PluggableListMorph and the other PluggableMorph classes. #update: compares the argument with the listGetter (or the appropriate ivar for each morph). So, when the model does 'self changed: #messageCategoryList', all dependent morphs get message 'eachMorph update: #messageCategoryList'. And only those morphs that were configured to watch on this symbol with react. As I said before, this is the changed/update mechanism in MVC in Smalltlk-80. Using #when:send:to: insted would lead to better code. But documenting the current state of the system is needed and important, Cheers, Juan Vuletich From juan at jvuletich.org Fri Oct 23 12:22:19 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 14:22:19 -0300 Subject: [Cuis] veryShortName In-Reply-To: <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> Message-ID: <562A6CCB.6000603@jvuletich.org> On 17/10/2015 11:39 a.m., KenD wrote: > On Sat, 17 Oct 2015 14:28:23 +0900 > Masashi UMEZAWA wrote: > >> Perhaps #firstName or #nameUpToDot would be better? > Yes. Either works for me. > > Thanks, > KenD > Besides #shortName, we also have #splitNameVersionExtensionFor:, #baseNameFor:, #baseName, etc. Reducing their number would be good. As it would be to separate those that give a "standard service" from those that just solve a more specific need of some client code. Cheers, Juan Vuletich From juan at jvuletich.org Fri Oct 23 13:49:15 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 15:49:15 -0300 Subject: [Cuis] New Commit: FileMan adoption and tweaks Message-ID: <562A812B.7090101@jvuletich.org> Hi Folks, I've just updated github. I did many changes, to adopt FileMan almost everywhere in Cuis and core packages.I did a few changes to FileMan and the API. The one you might notice is that I've made FmFileEntry and FmDirectoryEntry siblings, under a new FmEntry. Now, each class is more specific: FmFileEntry doesn't handle Directory responsibilities (like creating files in it) and FmDirectoryEntry doesn't support File responsibility (like creating a FileStream on itself). I think it is much cleaner this way. The change you might need to care about is that 'dirName' asDirectoryEntry / 'subdir' answers an FmDirectoryEntry and the new #//: 'dirName' asDirectoryEntry // 'filename' answers an FmFileEntry. Please adapt your packages to the new FileMan API, as the old FileDirectory hierarchy will be deprecated soon, and later removed from Cuis. Oh, this commit also includes new versions of TerseGuide and ClassCommentBrowser by Dan Norton. (Thanks Dan!) Cheers, Juan Vuletich From pbpublist at gmail.com Fri Oct 23 16:10:42 2015 From: pbpublist at gmail.com (Phil (list)) Date: Fri, 23 Oct 2015 17:10:42 -0400 Subject: [Cuis] Effect of Cursor Movement In-Reply-To: <55F307E2.4040706@jvuletich.org> References: <55F2FF07.16923.7339F5@dnorton.mindspring.com> <55F307E2.4040706@jvuletich.org> Message-ID: <1445634642.3451.6.camel@gmail.com> On Fri, 2015-09-11 at 13:57 -0300, Juan Vuletich wrote: > Hi Dan, > > (below) > On 9/11/2015 1:19 PM, Dan Norton wrote: > > Hello, > > > > To see this, Bring up BouncingAtomsMorph, enlarge the window, set a > > high atoms count so > > that you can easily sense atom movement. > > > > Notice how movement speeds up when the cursor is moved and slows > > when it stops? Turn > > on FPS. On my machine, frame rate is about 22 with no cursor > > movement and increases to > > around 36 when the cursor is moving. The cursor does not have to be > > in the window. It can > > be anywhere. > > > > Why should that be? It may not be a problem, but it is a curiosity. > > Any explanation? > > > > BTW this is Win7, cogwin-15.33.3427, Cuis 2478. > > > > ? - Dan > > Haven't even taken a look, so if I did maybe I would find something > else... but for sure Cuis is triggering MouseMoveEvents, and looking > for > possible interested parties. That, on each Morphic cycle. So, each > Morphic cycle might take a bit longer, and FPS can go a bit down. > > In any case, if you are curious, you can take a closer look. Often, > questions like this lead to possible optimizations! > The issue he's describing sounds like the opposite of that. ?Any chance this is related to the issue we discussed on vm-dev back in 2012? (The thread was titled "Cog VM idling performance") ?Your fix back then mostly addressed the issue (I've noticed some minor idling slowdowns since then, but nothing as extreme as when I originally reported the issue) Funny thing is I think I'm now dealing with the other side of this problem in Seaside: I have a situation where an idling VM is consuming too much CPU... (nothing specifically related to Cuis other than the warning to 'be careful of what you wish for' :-) > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org From dnorton at mindspring.com Fri Oct 23 18:04:27 2015 From: dnorton at mindspring.com (Dan Norton) Date: Fri, 23 Oct 2015 19:04:27 -0400 Subject: [Cuis] PluggableListMorph In-Reply-To: <562A677F.50500@jvuletich.org> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <562A58AA.15972.4E08E7@dnorton.mindspring.com>, <562A677F.50500@jvuletich.org> Message-ID: <562ABCFB.20558.1D5E5B6@dnorton.mindspring.com> On 23 Oct 2015 at 13:59, Juan Vuletich wrote: > On 23/10/2015 12:56 p.m., Dan Norton wrote: > > On 22 Oct 2015 at 15:39, KenD wrote: > > > >> On Tue, 20 Oct 2015 16:43:02 -0400 > >> "Dan Norton" wrote: > >> > >>> PluggableListMorph has valuable behavior but applying it in > morphs > >> with multiple lists can be > >>> daunting because of the use of the dependency mechanism. > AFAICT > >> the tools do not display > >>> dependencies and even if they did, it's not clear why some of > them > >> exist. > >>> What is needed is a "PluggableListMorph Principles of > Operation" > >> doc, or something similar > >>> that can be in the Terse Guide. It should show an example of > >> selection in one list causing the > >>> population of another list and selection in that list causing > the > >> population of some other > >>> morph. Isn't that like FileList? Yes, but we need the whys and > >> wherefors. For example, a > >>> method sends #changed: with a parameter referring to another > >> method - why? The design > >>> needs to be explained. > >> Dan, > >> > >> +1 > >> > >> A tool to detect/show such "out of band" control/change > >> linkages/dependencies would be most welcomed, as would a > Principles > >> of Operation. > >> > >> Taking a quick look at my own code ("guilty as charged, sir") > >> > >>>> grep "changed:" */*.st > >> Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph > >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: > #actualContents! > >> ! > >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. > >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > >> #actualContents! ! > >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > #refetched. > >> > > Hi Ken, > > > > In #actualContents: there is "self changed: #actualContents" which > seems reasonable. > > > > However, in #refetch there is "self changed: #refetch" which is > perplexing because it looks > > like infinite recursion, but it must be OK because similar > examples appear in Browser. > > > > - Dan > > Just look at senders of #refetched . (not refetch!) It is quite > simple, > actually. > > To see a bit more on how lists are used, see references to > PluggableListMorph. The second is #buildMorphicMessageCatList. See > how > it parametrizes the instance it builds. These methods that create > various lists are quite similar, and all they do is to bind each > list > with a different aspect of the model. In this case, with > #messageCategoryList. See implementors and senders. It is clear that > the > implementors are methods in models that answer (guess what!!!!) a > list > of message categories. When you look at senders senders, you can see > that some are in the model, doing things like 'self changed: > #messageCategoryList'. It is easy to see that this means that the > list > of message categories have changed, and anybody depending on that > should > update itself. > > Now we have a detail that is not that obvious, and most likely the > clue > you need to understand this all. See implementors of #update: in > PluggableListMorph and the other PluggableMorph classes. #update: > compares the argument with the listGetter (or the appropriate ivar > for > each morph). So, when the model does 'self changed: > #messageCategoryList', all dependent morphs get message 'eachMorph > update: #messageCategoryList'. And only those morphs that were > configured to watch on this symbol with react. > > As I said before, this is the changed/update mechanism in MVC in > Smalltlk-80. Ah. That's the key - I haven't looked at MVC in years. The model need not know about any view. It is the dependee, signalling happenings that the dependents might like to know. What dependents do starts with their #update: message which may take action after looking at the parameter (or not). The views are dependents of the model. It's misleading when parameters of #changed: look just like message selectors in the model. It gives the impression that those messages are to be sent or invoked, when all that's necessary is that the parameter be understood by the model. That is why it looks like infinite recursion when a method says: refetched ... self changed: #refetched. Far better if the parameter was "foobar or #putDataInTheTextMorphs or the like. > Using #when:send:to: insted would lead to better code. I will definitely start doing that. > But > documenting the current state of the system is needed and > important, With this insight, I may be able to do that now. - Dan From Ken.Dickey at Whidbey.com Fri Oct 23 22:50:16 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Fri, 23 Oct 2015 20:50:16 -0700 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <562A812B.7090101@jvuletich.org> References: <562A812B.7090101@jvuletich.org> Message-ID: <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> On Fri, 23 Oct 2015 15:49:15 -0300 Juan Vuletich wrote: > Hi Folks, > > I've just updated github. I did many changes, to adopt FileMan almost > everywhere in Cuis and core packages. You might want to update: SystemDictionary>>openSourcesAndChanges BTW, I was using String>>upToLastPathSeparator Any chance of getting it back? Cheers, -KenD -------------- next part -------------- A non-text attachment was scrubbed... Name: invoke.out Type: application/octet-stream Size: 3041 bytes Desc: not available URL: From ume at blueplane.jp Sun Oct 25 09:15:18 2015 From: ume at blueplane.jp (Masashi UMEZAWA) Date: Sun, 25 Oct 2015 23:15:18 +0900 Subject: [Cuis] veryShortName In-Reply-To: <562A6CCB.6000603@jvuletich.org> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> <562A6CCB.6000603@jvuletich.org> Message-ID: Hi all, Indeed, we should avoid adding ad-hoc methods. Currently I'm thinking to introduce a more generic API (splitName:by:) to FmFileIOAccessor. So we can implement FmFileEntry methods more consistently like: FmFileEntry >> firstName ^ (self fileAccessor splitName: self name by: self extensionDelimiter) first FmFileEntry >> extension ^ (self fileAccessor splitName: self name by: self extensionDelimiter) last FmFileEntry >> baseName | names | names := self fileAccessor splitName: self name by: self extensionDelimiter. names size = 1 ifTrue: [^names first]. ^self extensionDelimiter join: names allButLast Best regards, 2015-10-24 2:22 GMT+09:00 Juan Vuletich : > On 17/10/2015 11:39 a.m., KenD wrote: >> >> On Sat, 17 Oct 2015 14:28:23 +0900 >> Masashi UMEZAWA wrote: >> >>> Perhaps #firstName or #nameUpToDot would be better? >> >> Yes. Either works for me. >> >> Thanks, >> KenD >> > > Besides #shortName, we also have #splitNameVersionExtensionFor:, > #baseNameFor:, #baseName, etc. Reducing their number would be good. As it > would be to separate those that give a "standard service" from those that > just solve a more specific need of some client code. > > Cheers, > Juan Vuletich -- [:masashi | ^umezawa] From pavel.krivanek at gmail.com Sun Oct 25 10:36:09 2015 From: pavel.krivanek at gmail.com (Pavel Krivanek) Date: Sun, 25 Oct 2015 16:36:09 +0100 Subject: [Cuis] smallest Cuis image with Morphic Message-ID: Hi, is there the old minimal Cuis image (about 2MB with Morphic) still somewhere to download? Cheers, -- Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Sun Oct 25 11:19:38 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sun, 25 Oct 2015 09:19:38 -0700 Subject: [Cuis] veryShortName In-Reply-To: References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> <562A6CCB.6000603@jvuletich.org> Message-ID: <20151025091938.1f28b5c26bb7cdbb5d462c6c@Whidbey.com> On Sun, 25 Oct 2015 23:15:18 +0900 Masashi UMEZAWA wrote: > Currently I'm thinking to introduce a more generic API (splitName:by:) > to FmFileIOAccessor. That would be great! Juan, would you let me know when this is integrated? I/we need to update/replace StandardFileMenu. Thanks much, -KenD From 0800nacho at gmail.com Sun Oct 25 13:03:27 2015 From: 0800nacho at gmail.com (nacho) Date: Sun, 25 Oct 2015 11:03:27 -0700 (PDT) Subject: [Cuis] Changing Wallpaper Message-ID: <1445796207751-4857882.post@n4.nabble.com> Hi Folks, I know how to take out the default Cuis wallpaper and change it with a solid color. However, I'm not able to use another image. What are the steps needed to get this done? Thanks in advance Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Sun Oct 25 17:11:26 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Sun, 25 Oct 2015 19:11:26 -0300 Subject: [Cuis] smallest Cuis image with Morphic In-Reply-To: References: Message-ID: <562D538E.5090406@jvuletich.org> On 25/10/2015 12:36 p.m., Pavel Krivanek wrote: > Hi, > > is there the old minimal Cuis image (about 2MB with Morphic) still > somewhere to download? > > Cheers, > -- Pavel > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org Hi Pavel, Yes. It is still at www.jvuletich.org/Cuis/Cuis3.1r3.zip . You'll need a sources file. You can get it from www.jvuletich.org/Cuis/Cuis3.1-0850.zip . Please note that it is possible to build such a small image from a current Cuis, if desired. Cheers, Juan Vuletich Ps. I'm sure you're on something interesting with this. Could you please tell a bit? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Sun Oct 25 17:56:31 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sun, 25 Oct 2015 15:56:31 -0700 Subject: [Cuis] smallest Cuis image with Morphic In-Reply-To: <562D538E.5090406@jvuletich.org> References: <562D538E.5090406@jvuletich.org> Message-ID: <20151025155631.e9f696d0b85c0bcff578f5ed@Whidbey.com> On Sun, 25 Oct 2015 19:11:26 -0300 Juan Vuletich wrote: .. > Please note that it is possible to build such a small image from a > current Cuis, if desired. BTW, I tried Smalltalk reduceCuis. in 2555 but it seems to go into a loop at AnObsoleteUnixFileDirectory class(FileDirectory class)>>pathDelimiter Smalltalk reduceCuis. is successful under 2528 and produces 4.8 Mb image FYI, -KenD From dnorton at mindspring.com Mon Oct 26 15:58:12 2015 From: dnorton at mindspring.com (Dan Norton) Date: Mon, 26 Oct 2015 16:58:12 -0400 Subject: [Cuis] PluggableListMorph Message-ID: <562E93E4.6994.128E352@dnorton.mindspring.com> Hello All, Please review the following for accuracy. It's not complete. It's a start on a "Principles of Operation" for applying PluggableListMorph for fun and profit. Maybe it should be called "PluggableListMorph for Dummies". I'm especially interested in whether you agree with the "coincidental" statement. PluggableListMorph is designed to work as part of one or more views on a model in the MVC paradigm (Note 1). The model is not directly aware of the existence of any view; instead, it signals changes in itself by broadcasting symbols with the #changed: method. In this way, any view which is related to the model can detect the changes by examining the symbol in its #update: method. Thus while the model is not explicitly aware of a view, there is an implicit relationship in that a view must know the significance of the symbols broadcast by the model in order to respond appropriately. Views are dependents of a model and therefore the model is a sponsor of views. Use of the #changed: and #update: methods is the essence of the Smalltalk dependency mechanism (Inside II). The model sends #changed: and as a result, all dependents (e.g. views) on it receive #update:. In the #update: method, the view examines the symbol and decides what, if anything, to do. While the symbol is, in practice, often identical to the name of a method, this is coincidental and unfortunately a source of confusion and misdirection. Note 1. The MVC paradigm is mentioned here for historical context. PluggableListMorph can also be employed in other design schemes. Inside II. LaLonde and Pugh, "Inside Smalltalk, Volume II" Thanks, - Dan From Ken.Dickey at Whidbey.com Mon Oct 26 17:39:42 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Mon, 26 Oct 2015 15:39:42 -0700 Subject: [Cuis] PluggableListMorph In-Reply-To: <562E93E4.6994.128E352@dnorton.mindspring.com> References: <562E93E4.6994.128E352@dnorton.mindspring.com> Message-ID: <20151026153942.aebae2c125a712e22f4b9fa6@Whidbey.com> Hi Dan, Good explanation. I like good explanations. 8) You might be interested in the code examples in: http://stackoverflow.com/questions/17082576/implementing-the-observer-pattern-in-smalltalk-visualworks I would note that the observer pattern discussion might be better served by the more modern #when:send:to: idiom. [E.g. look at when:send:to: senders; Check the TaskBar for simple usage]. In particular, an observer can register for event updates and get a specific message. IMHO we should rewrite PluggableListMorph to use when:send:to: $0.02 -KenD From 0800nacho at gmail.com Tue Oct 27 10:02:53 2015 From: 0800nacho at gmail.com (nacho) Date: Tue, 27 Oct 2015 08:02:53 -0700 (PDT) Subject: [Cuis] Changing Wallpaper In-Reply-To: <1445796207751-4857882.post@n4.nabble.com> References: <1445796207751-4857882.post@n4.nabble.com> Message-ID: <1445958173832-4858215.post@n4.nabble.com> It seems that I have to convert the image as an array, isn't it? ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882p4858215.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From dnorton at mindspring.com Tue Oct 27 10:23:49 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 27 Oct 2015 11:23:49 -0400 Subject: [Cuis] Could Not Find Feature Requirement Message-ID: <562F9705.519.430ADA@dnorton.mindspring.com> Cuis4.2-2528 successfully loads a package with a feature requirement. With Cuis4.2-2555, loading the same package gets: Error:Could not find package supplying feature: FeatureRequirement(Records 1.15 to *.*) - Dan From hannes.hirzel at gmail.com Tue Oct 27 11:27:58 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue, 27 Oct 2015 17:27:58 +0100 Subject: [Cuis] Changing Wallpaper In-Reply-To: <1445958173832-4858215.post@n4.nabble.com> References: <1445796207751-4857882.post@n4.nabble.com> <1445958173832-4858215.post@n4.nabble.com> Message-ID: Have a look at PasteUpMorph >> backgroundImageData: aByteArray Then do something like | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: (FileStream readOnlyFileNamed: filename) binary contentsOfEntireFile. HTH --Hannes On 10/27/15, nacho <0800nacho at gmail.com> wrote: > It seems that I have to convert the image as an array, isn't it? > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/Changing-Wallpaper-tp4857882p4858215.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From dnorton at mindspring.com Tue Oct 27 13:04:10 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 27 Oct 2015 14:04:10 -0400 Subject: [Cuis] Could Not Find Feature Requirement Message-ID: <562FBC9A.2992.D5D887@dnorton.mindspring.com> If a copy of the required feature is placed in the directory of the image, the package loads successfully, - Dan From 0800nacho at gmail.com Tue Oct 27 15:29:37 2015 From: 0800nacho at gmail.com (nacho) Date: Tue, 27 Oct 2015 13:29:37 -0700 (PDT) Subject: [Cuis] Changing Wallpaper In-Reply-To: References: <1445796207751-4857882.post@n4.nabble.com> <1445958173832-4858215.post@n4.nabble.com> Message-ID: <1445977777218-4858263.post@n4.nabble.com> Thank you !!! That worked perfectly!! ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882p4858263.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Wed Oct 28 09:14:57 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:14:57 -0300 Subject: [Cuis] Effect of Cursor Movement In-Reply-To: <1445634642.3451.6.camel@gmail.com> References: <55F2FF07.16923.7339F5@dnorton.mindspring.com> <55F307E2.4040706@jvuletich.org> <1445634642.3451.6.camel@gmail.com> Message-ID: <5630D861.2090509@jvuletich.org> Hi Folks, (inline) On 10/23/2015 6:10 PM, Phil (list) wrote: > On Fri, 2015-09-11 at 13:57 -0300, Juan Vuletich wrote: >> Hi Dan, >> >> (below) >> On 9/11/2015 1:19 PM, Dan Norton wrote: >>> Hello, >>> >>> To see this, Bring up BouncingAtomsMorph, enlarge the window, set a >>> high atoms count so >>> that you can easily sense atom movement. >>> >>> Notice how movement speeds up when the cursor is moved and slows >>> when it stops? Turn >>> on FPS. On my machine, frame rate is about 22 with no cursor >>> movement and increases to >>> around 36 when the cursor is moving. The cursor does not have to be >>> in the window. It can >>> be anywhere. >>> >>> Why should that be? It may not be a problem, but it is a curiosity. >>> Any explanation? >>> >>> BTW this is Win7, cogwin-15.33.3427, Cuis 2478. >>> >>> - Dan >> Haven't even taken a look, so if I did maybe I would find something >> else... but for sure Cuis is triggering MouseMoveEvents, and looking >> for >> possible interested parties. That, on each Morphic cycle. So, each >> Morphic cycle might take a bit longer, and FPS can go a bit down. >> >> In any case, if you are curious, you can take a closer look. Often, >> questions like this lead to possible optimizations! >> > The issue he's describing sounds like the opposite of that. Any chance > this is related to the issue we discussed on vm-dev back in 2012? (The > thread was titled "Cog VM idling performance") Your fix back then > mostly addressed the issue (I've noticed some minor idling slowdowns > since then, but nothing as extreme as when I originally reported the > issue) Thanks for the heads-up. You are right. The issue is related to that code. I fixed it, and now BouncingAtomsMorph fps is quite better and independent of user activity! > Funny thing is I think I'm now dealing with the other side of this > problem in Seaside: I have a situation where an idling VM is consuming > too much CPU... (nothing specifically related to Cuis other than the > warning to 'be careful of what you wish for' :-) Check for #serverMode. This sould fix that problem. You can tweak it to devote very little cpu to Morphic (with sluggish Morphic when you need it). Squeak also has it. Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:16:14 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:16:14 -0300 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> Message-ID: <5630D8AE.8030803@jvuletich.org> Hi Ken, On 10/24/2015 12:50 AM, KenD wrote: > On Fri, 23 Oct 2015 15:49:15 -0300 > Juan Vuletich wrote: > >> Hi Folks, >> >> I've just updated github. I did many changes, to adopt FileMan almost >> everywhere in Cuis and core packages. > You might want to update: > SystemDictionary>>openSourcesAndChanges Of course. Done. I've just commited an image that no longer includes FileDirectory!!! > BTW, I was using String>>upToLastPathSeparator > > Any chance of getting it back? Sure. Added it back. > Cheers, > -KenD Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:19:05 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:19:05 -0300 Subject: [Cuis] Could Not Find Feature Requirement In-Reply-To: <562F9705.519.430ADA@dnorton.mindspring.com> References: <562F9705.519.430ADA@dnorton.mindspring.com> Message-ID: <5630D959.5040903@jvuletich.org> On 10/27/2015 12:23 PM, Dan Norton wrote: > Cuis4.2-2528 successfully loads a package with a feature requirement. > > With Cuis4.2-2555, loading the same package gets: > > Error:Could not find package supplying feature: FeatureRequirement(Records 1.15 to *.*) > > - Dan > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > Please try with the latest image. If you still have problems, give details about the directory structure that makes it fail. Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:55:12 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:55:12 -0300 Subject: [Cuis] New Commit: FileDirectory finally gone! Message-ID: <5630E1D0.7070907@jvuletich.org> Hi Folks, I finished the migration to FileMan. I removed the FileDirectory and DirectoryEntry hierarchies. I also removed a few rather ambiguous creation methods in StandardFileStream. Please update your packages and code accordingly. FileMan is so much nicer to use! Especially, prefer #writeStream: and #readStream: methods, that do the close for you (even in the presence of errors, etc). There might be details that still need tweaking. Let's go into a stabilization phase with this. When we are all happy, we can call it Cuis 5.0. Cuis keeps showing us that constant cleaning and simplification enables this kind of deep changes and evolution. This is so much better than simply adding yet-another-API-for-doing-the-same-thing, as other Smalltalk environments are forced to do! Cheers, Juan Vuletich From garduino at gmail.com Wed Oct 28 10:25:45 2015 From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=) Date: Wed, 28 Oct 2015 12:25:45 -0300 Subject: [Cuis] New Commit: FileDirectory finally gone! In-Reply-To: <5630E1D0.7070907@jvuletich.org> References: <5630E1D0.7070907@jvuletich.org> Message-ID: +1 ! Saludos / Regards, Germ?n Arduino @garduino 2015-10-28 11:55 GMT-03:00 Juan Vuletich : > Hi Folks, > > I finished the migration to FileMan. I removed the FileDirectory and > DirectoryEntry hierarchies. I also removed a few rather ambiguous creation > methods in StandardFileStream. Please update your packages and code > accordingly. FileMan is so much nicer to use! Especially, prefer > #writeStream: and #readStream: methods, that do the close for you (even in > the presence of errors, etc). > > There might be details that still need tweaking. Let's go into a > stabilization phase with this. When we are all happy, we can call it Cuis > 5.0. > > Cuis keeps showing us that constant cleaning and simplification enables > this kind of deep changes and evolution. This is so much better than simply > adding yet-another-API-for-doing-the-same-thing, as other Smalltalk > environments are forced to do! > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Wed Oct 28 11:05:34 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Wed, 28 Oct 2015 09:05:34 -0700 Subject: [Cuis] New Commit: FileDirectory finally gone! In-Reply-To: <5630E1D0.7070907@jvuletich.org> References: <5630E1D0.7070907@jvuletich.org> Message-ID: <20151028090534.bdade822ea0f0e0ca2739444@Whidbey.com> On Wed, 28 Oct 2015 11:55:12 -0300 Juan Vuletich wrote: > There might be details that still need tweaking. Let's go into a > stabilization phase with this. When we are all happy, we can call it > Cuis 5.0. WooHoo! 8^) > Cuis keeps showing us that constant cleaning and simplification enables > this kind of deep changes and evolution. This is so much better than > simply adding yet-another-API-for-doing-the-same-thing, as other > Smalltalk environments are forced to do! Just tries Solitaire and noted it is significant faster. Current Class count is 504. Juan, you have much to be proud about. Thanks once again for Cuis!!! -- -KenD ================ count := 0. Metaclass allInstancesDo: [ :ignore | count := count + 1 ]. count. "==> 504" ================ From dnorton at mindspring.com Wed Oct 28 13:29:13 2015 From: dnorton at mindspring.com (Dan Norton) Date: Wed, 28 Oct 2015 14:29:13 -0400 Subject: [Cuis] Could Not Find Feature Requirement In-Reply-To: <5630D959.5040903@jvuletich.org> References: <562F9705.519.430ADA@dnorton.mindspring.com>, <5630D959.5040903@jvuletich.org> Message-ID: <563113F9.4492.E99BF5@dnorton.mindspring.com> On 28 Oct 2015 at 11:19, Juan Vuletich wrote: > On 10/27/2015 12:23 PM, Dan Norton wrote: > > Cuis4.2-2528 successfully loads a package with a feature > requirement. > > > > With Cuis4.2-2555, loading the same package gets: > > > > Error:Could not find package supplying feature: > FeatureRequirement(Records 1.15 to *.*) > > > > - Dan > > > > _______________________________________________ > > Cuis mailing list > > Cuis at jvuletich.org > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > Please try with the latest image. If you still have problems, give > details about the directory structure that makes it fail. > Hi Juan, You fixed it in Cuis4.2-2563! Thanks much! - Dan From 0800nacho at gmail.com Wed Oct 28 14:18:55 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 12:18:55 -0700 (PDT) Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <5630D8AE.8030803@jvuletich.org> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> Message-ID: <1446059935002-4858359.post@n4.nabble.com> So now, for importing a new wallpaper, instead of doing: | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: (FileStream readOnlyFileNamed: filename) binary contentsOfEntireFile. What Class and method should I use? Because FileStream>>readOnlyFileNamed: is no longer there. thanks in advance! nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From hannes.hirzel at gmail.com Wed Oct 28 16:38:18 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Wed, 28 Oct 2015 22:38:18 +0100 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <1446059935002-4858359.post@n4.nabble.com> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: filename asFileEntry binaryContents. On 10/28/15, nacho <0800nacho at gmail.com> wrote: > So now, for importing a new wallpaper, instead of doing: > > | filename | > filename _ 'Pluto.png'. > self runningWorld backgroundImageData: > (FileStream readOnlyFileNamed: filename) binary > contentsOfEntireFile. > > What Class and method should I use? Because FileStream>>readOnlyFileNamed: > is no longer there. > thanks in advance! > nacho > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From hannes.hirzel at gmail.com Wed Oct 28 16:50:32 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Wed, 28 Oct 2015 22:50:32 +0100 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: N.B. Have a look at the class comment of FmFileEntry and the seven example methods on the class side. And String>>asFileEntry There is a need for an example for #binaryContents and #binaryContents: On 10/28/15, H. Hirzel wrote: > | filename | > filename _ 'Pluto.png'. > self runningWorld backgroundImageData: filename asFileEntry > binaryContents. > > > On 10/28/15, nacho <0800nacho at gmail.com> wrote: >> So now, for importing a new wallpaper, instead of doing: >> >> | filename | >> filename _ 'Pluto.png'. >> self runningWorld backgroundImageData: >> (FileStream readOnlyFileNamed: filename) binary >> contentsOfEntireFile. >> >> What Class and method should I use? Because >> FileStream>>readOnlyFileNamed: >> is no longer there. >> thanks in advance! >> nacho >> >> >> >> >> ----- >> Nacho >> Smalltalker apprentice. >> Buenos Aires, Argentina. >> -- >> View this message in context: >> http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html >> Sent from the Cuis Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Cuis mailing list >> Cuis at jvuletich.org >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> > From 0800nacho at gmail.com Wed Oct 28 17:53:05 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 15:53:05 -0700 (PDT) Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: <1446072785216-4858383.post@n4.nabble.com> Hannes, Thanks again so much! cheers Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858383.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From 0800nacho at gmail.com Wed Oct 28 18:26:28 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 16:26:28 -0700 (PDT) Subject: [Cuis] VM Crashing when loading Themes pkg Message-ID: <1446074788550-4858389.post@n4.nabble.com> I'm trying to load the themes pkg using the latest Cuis image and every time I try to do it the VM crashes. I was using the last Cog vm from Eliot's place. I tried using previous vms but the result is the same. I've tried with other packages and the effect is the same: vm crashes. I'm in OSX 10.11.1 I attach the crash.dmp file Could it be due to the changes in the FM? Anyone is having the same crashes? Thanks Nacho crash.dmp ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/VM-Crashing-when-loading-Themes-pkg-tp4858389.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Thu Oct 29 07:37:57 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Thu, 29 Oct 2015 09:37:57 -0300 Subject: [Cuis] VM Crashing when loading Themes pkg In-Reply-To: <1446074788550-4858389.post@n4.nabble.com> References: <1446074788550-4858389.post@n4.nabble.com> Message-ID: <56321325.6080504@jvuletich.org> Hi Nacho, Please use Cog #3370 as indicated in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/GettingStarted-UsingCommandline.md and other documentation there. Cheers, Juan Vuletich On 10/28/2015 8:26 PM, nacho wrote: > I'm trying to load the themes pkg using the latest Cuis image and every time > I try to do it the VM crashes. > I was using the last Cog vm from Eliot's place. I tried using previous vms > but the result is the same. > I've tried with other packages and the effect is the same: vm crashes. > I'm in OSX 10.11.1 > I attach the crash.dmp file > > Could it be due to the changes in the FM? > Anyone is having the same crashes? > Thanks > Nacho > > crash.dmp > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/VM-Crashing-when-loading-Themes-pkg-tp4858389.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From 0800nacho at gmail.com Thu Oct 29 07:52:39 2015 From: 0800nacho at gmail.com (nacho) Date: Thu, 29 Oct 2015 05:52:39 -0700 (PDT) Subject: [Cuis] VM Crashing when loading Themes pkg In-Reply-To: <56321325.6080504@jvuletich.org> References: <1446074788550-4858389.post@n4.nabble.com> <56321325.6080504@jvuletich.org> Message-ID: <1446123159957-4858467.post@n4.nabble.com> Thank you Juan! I tried a lot of vms but don't reached build 3370. And I should have read the documentation, sorry. best Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/VM-Crashing-when-loading-packages-tp4858389p4858467.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From Ken.Dickey at Whidbey.com Thu Oct 29 18:56:50 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Thu, 29 Oct 2015 16:56:50 -0700 Subject: [Cuis] ColorEditor updated Message-ID: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> Hi all, I updated Morphic-ColorEditor for simpler layout and font preferences updating. I also updated Morphic-Misc1 for font preferences update. Dan, note that the Morphic-ColorEditor uses #when:send:to: for updates. You can file it in and check senders. Bugs to /dev/null, er, I mean to me. ;^) Cheers, -KenD From 0800nacho at gmail.com Fri Oct 30 19:08:02 2015 From: 0800nacho at gmail.com (nacho) Date: Fri, 30 Oct 2015 17:08:02 -0700 (PDT) Subject: [Cuis] a simple method to change the wallpaper Message-ID: <1446250082444-4858760.post@n4.nabble.com> PasteUpMorph>>setBackgroundImage: aFilename "Sets the graphic file provided as a wallpaper" self runningWorld backgroundImageData: aFilename asFileEntry binaryContents. Then you go to the File List and copy the name of the file in the clipboard. Open a workspace: self runningWorld setBackgroundImage: '' screenshot.jpg ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/a-simple-method-to-change-the-wallpaper-tp4858760.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From dnorton at mindspring.com Sat Oct 31 21:01:06 2015 From: dnorton at mindspring.com (Dan Norton) Date: Sat, 31 Oct 2015 22:01:06 -0400 Subject: [Cuis] ColorEditor updated In-Reply-To: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> Message-ID: <56357262.9599.2DA3199@dnorton.mindspring.com> On 29 Oct 2015 at 16:56, KenD wrote: > Hi all, > > I updated Morphic-ColorEditor for simpler layout and font > preferences updating. > > I also updated Morphic-Misc1 for font preferences update. > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for > updates. You can file it in and check senders. > I've done that and I see that messages to SystemChangeNotifier are not required in order to use the method. Also, the dependency mechanism itself uses #when:send:to:. Any object can use #when:send:to: because it is an Object instance method. So, should this be named a different mechanism or is it just a different use of the dependency mechanism? If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#Featu reComparison - Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan at jvuletich.org Tue Oct 6 07:24:48 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Tue, 06 Oct 2015 09:24:48 -0300 Subject: [Cuis] Class Comment Browser In-Reply-To: <560C57DC.32345.163B7FF@dnorton.mindspring.com> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <4f00e132cd45e6e377ff945fafa610b0.squirrel@gator3294.hostgator.com> <560C57DC.32345.163B7FF@dnorton.mindspring.com> Message-ID: <5613BD90.4040204@jvuletich.org> Hi Dan, Apologies for the long delay in answering. I think you mean the text styler, that colorizes Smalltalk code, right? Well, an instance of InnerTextMorph might have a subinstance of SHTextStyler in the 'styler' variable. This is "Shout", originally from Squeak. But it might be disabled sometimes, as when the code pane is showing diffs, or bytecodes, etc. See #okToStyle , where the model is asked whether it is appropriate to style each time. If you can't solve the problem, point me to the latest version of CCB, and briefly describe steps, expected behavior, unwanted behavior (to be sure I understand), and I'll take a look. Cheers, Juan Vuletich On 30/09/2015 06:45 p.m., Dan Norton wrote: > Hi Juan, > > The editor class seems to remain constant as SmalltalkEditor. To see what is puzzling: > > open a browser on a class with an actual comment > view the class comment (? button) > select all of the comment and copy it > select, then deselect a message category > paste the comment in the code window as if defining a new method > see the difference in presentation > > What is making this switch? If I knew where this is done I might get the behavior I want in > CCB. > > - Dan > > On 30 Sep 2015 at 8:19, Juan Vuletich wrote: > >> Hi Dan, >> >> See the TextEditor hierarchy. See #editorClass, senders and >> implementors. >> It is the model who decides what kind of editor to use. >> >> An easy way to find out about this, is to realiza that what you want >> is >> the "Smalltalk Options" menu in code panes. Just write "Smalltalk >> Options" >> in some code pane, select it (without the quotes) and do right click >> / >> Smalltalk Options / Method Source with it. That leads you right to >> SmalltalkEditor. >> >> Cheers, >> Juan Vuletich >> >> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: >>> Hi Juan, >>> >>> >>> A little help, please. BrowserWindow uses >>> CodeWindow>>buildMorphicCodePane for the >>> class comment area. Although this area looks like text, >> expressions >>> appearing in class comments can be executed as in a workspace. >>> >>> I want the same behavior in Class Comment Browser, but all I get >> is text >>> behavior (no execution). How can this be changed? >>> >>> - Dan >>> >>> >>> _______________________________________________ >>> Cuis mailing list >>> Cuis at jvuletich.org >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >> >> _______________________________________________ >> Cuis mailing list >> Cuis at jvuletich.org >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From dnorton at mindspring.com Tue Oct 6 20:17:11 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 06 Oct 2015 21:17:11 -0400 Subject: [Cuis] Class Comment Browser In-Reply-To: <5613BD90.4040204@jvuletich.org> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <560C57DC.32345.163B7FF@dnorton.mindspring.com>, <5613BD90.4040204@jvuletich.org> Message-ID: <56147297.21959.20BF33E@dnorton.mindspring.com> Hi Juan, Delay? What delay? Not to worry :-) I regret that this problem is either beyond me or I'm blind to it. Had to clean up the act a bit because of all the fruitless experiments but the repo seems to behave OK. It is strongly desired by the (huge?) user community that the pane containing the comment would behave like a work space, e.g. allow statements to be executed and names to be highlighted and used to open a browser. The repo is: https://github.com/dhnorton/Cuis-Smalltalk-comments Please let me know what I need to do. - Dan On 6 Oct 2015 at 9:24, Juan Vuletich wrote: > Hi Dan, > > Apologies for the long delay in answering. > > I think you mean the text styler, that colorizes Smalltalk code, > right? > Well, an instance of InnerTextMorph might have a subinstance of > SHTextStyler in the 'styler' variable. This is "Shout", originally > from > Squeak. But it might be disabled sometimes, as when the code pane is > showing diffs, or bytecodes, etc. See #okToStyle , where the model > is > asked whether it is appropriate to style each time. > > If you can't solve the problem, point me to the latest version of > CCB, > and briefly describe steps, expected behavior, unwanted behavior (to > be > sure I understand), and I'll take a look. > > Cheers, > Juan Vuletich > > On 30/09/2015 06:45 p.m., Dan Norton wrote: > > Hi Juan, > > > > The editor class seems to remain constant as SmalltalkEditor. To > see what is puzzling: > > > > open a browser on a class with an actual comment > > view the class comment (? button) > > select all of the comment and copy it > > select, then deselect a message category > > paste the comment in the code window as if defining a new > method > > see the difference in presentation > > > > What is making this switch? If I knew where this is done I might > get the behavior I want in > > CCB. > > > > - Dan > > > > On 30 Sep 2015 at 8:19, Juan Vuletich wrote: > > > >> Hi Dan, > >> > >> See the TextEditor hierarchy. See #editorClass, senders and > >> implementors. > >> It is the model who decides what kind of editor to use. > >> > >> An easy way to find out about this, is to realiza that what you > want > >> is > >> the "Smalltalk Options" menu in code panes. Just write > "Smalltalk > >> Options" > >> in some code pane, select it (without the quotes) and do right > click > >> / > >> Smalltalk Options / Method Source with it. That leads you right > to > >> SmalltalkEditor. > >> > >> Cheers, > >> Juan Vuletich > >> > >> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: > >>> Hi Juan, > >>> > >>> > >>> A little help, please. BrowserWindow uses > >>> CodeWindow>>buildMorphicCodePane for the > >>> class comment area. Although this area looks like text, > >> expressions > >>> appearing in class comments can be executed as in a workspace. > >>> > >>> I want the same behavior in Class Comment Browser, but all I > get > >> is text > >>> behavior (no execution). How can this be changed? > >>> > >>> - Dan > >>> > >>> > >>> _______________________________________________ > >>> Cuis mailing list > >>> Cuis at jvuletich.org > >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > >>> > >>> > >> > >> _______________________________________________ > >> Cuis mailing list > >> Cuis at jvuletich.org > >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > > _______________________________________________ > > Cuis mailing list > > Cuis at jvuletich.org > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > From juan at jvuletich.org Wed Oct 7 07:17:40 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 7 Oct 2015 09:17:40 -0300 Subject: [Cuis] Class Comment Browser In-Reply-To: <56147297.21959.20BF33E@dnorton.mindspring.com> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <560C57DC.32345.163B7FF@dnorton.mindspring.com>, <5613BD90.4040204@jvuletich.org> <56147297.21959.20BF33E@dnorton.mindspring.com> Message-ID: <4f40bf8bef60787638764dcb4d9f9a20.squirrel@gator3294.hostgator.com> Hi Dan, If you inspect the InnerTextMorph in your right pane, it has: editor: aTextEditor styler: nil To be able to evaluate code, you need a SmalltalkEditor. This does the trick: CommentGuide >> editorClassFor: textGetter ^SmalltalkEditor If you also want Workspace like syntax highlighting, you need a TextStyler. Add: CommentGuide >> textStylerClassFor: textGetter ^SHTextStylerST80 CommentGuide >> shoutAboutToStyle: aSHTextStyler ^true Keep in mind that most class comments can not be parsed as code! That's why in the regular browser, methods are syntaxHighlighted, but class comments are not. I feel that with the hints I gave you before, you could have found out all this yourself. You will get the most out of Smalltalk if you use the code inspection tools as much as possible, and you are not afraid of exploring, experimenting, and trying to learn how the system works. Cheers, Juan Vuletich On Tue, October 6, 2015 10:17 pm, Dan Norton wrote: > Hi Juan, > > > Delay? What delay? Not to worry :-) I regret that this problem is either > beyond me or I'm blind to it. > > Had to clean up the act a bit because of all the fruitless experiments > but the repo seems to behave OK. It is strongly desired by the (huge?) > user community that the pane containing the comment would behave like a > work space, e.g. allow statements to be executed and names to be > highlighted and used to open a browser. The repo is: > > https://github.com/dhnorton/Cuis-Smalltalk-comments > > > Please let me know what I need to do. > > > - Dan > > > On 6 Oct 2015 at 9:24, Juan Vuletich wrote: > > >> Hi Dan, >> >> >> Apologies for the long delay in answering. >> >> >> I think you mean the text styler, that colorizes Smalltalk code, >> right? Well, an instance of InnerTextMorph might have a subinstance of >> SHTextStyler in the 'styler' variable. This is "Shout", originally >> from Squeak. But it might be disabled sometimes, as when the code pane is >> showing diffs, or bytecodes, etc. See #okToStyle , where the model is >> asked whether it is appropriate to style each time. >> >> If you can't solve the problem, point me to the latest version of >> CCB, >> and briefly describe steps, expected behavior, unwanted behavior (to be >> sure I understand), and I'll take a look. >> >> Cheers, >> Juan Vuletich >> >> >> On 30/09/2015 06:45 p.m., Dan Norton wrote: >> >>> Hi Juan, >>> >>> >>> The editor class seems to remain constant as SmalltalkEditor. To >>> >> see what is puzzling: >>> >>> open a browser on a class with an actual comment view the class >>> comment (? button) select all of the comment and copy it select, then >>> deselect a message category paste the comment in the code window as if >>> defining a new >> method >>> see the difference in presentation >>> >>> What is making this switch? If I knew where this is done I might >>> >> get the behavior I want in >>> CCB. >>> >>> >>> - Dan >>> >>> >>> On 30 Sep 2015 at 8:19, Juan Vuletich wrote: >>> >>> >>>> Hi Dan, >>>> >>>> >>>> See the TextEditor hierarchy. See #editorClass, senders and >>>> implementors. It is the model who decides what kind of editor to use. >>>> >>>> >>>> An easy way to find out about this, is to realiza that what you >>>> >> want >>>> is the "Smalltalk Options" menu in code panes. Just write >> "Smalltalk >> >>>> Options" >>>> in some code pane, select it (without the quotes) and do right >> click >>>> / >>>> Smalltalk Options / Method Source with it. That leads you right >>>> >> to >>>> SmalltalkEditor. >>>> >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> >>>> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: >>>> >>>>> Hi Juan, >>>>> >>>>> >>>>> >>>>> A little help, please. BrowserWindow uses >>>>> CodeWindow>>buildMorphicCodePane for the >>>>> class comment area. Although this area looks like text, >>>> expressions >>>>> appearing in class comments can be executed as in a workspace. >>>>> >>>>> I want the same behavior in Class Comment Browser, but all I >>>>> >> get >>>> is text >>>>> behavior (no execution). How can this be changed? >>>>> >>>>> - Dan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Cuis mailing list >>>>> Cuis at jvuletich.org >>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Cuis mailing list >>>> Cuis at jvuletich.org >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>> >>> >>> >>> _______________________________________________ >>> Cuis mailing list >>> Cuis at jvuletich.org >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >> > > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > From Ken.Dickey at Whidbey.com Mon Oct 12 10:05:16 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Mon, 12 Oct 2015 08:05:16 -0700 Subject: [Cuis] veryShortName Message-ID: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Greetings, I have been looking at FileMan and had some confusion with #FmFileEntry>>shortName. 'this.that.txt' asFileEntry name. ==> 'this.that.txt' 'this.that.txt' asFileEntry shortName. ==> 'this' I expected #shortName to answer the same result as baseName. 'this.that.txt' asFileEntry baseName. ==> 'this.that' I find the current behavior confusing. Is there a real need to have #shortName differ from #baseName? If the current #shortName behavior is required, could the name be changed to something nore mnemonic. Perhaps #firstPrefix ? Thanks much, -KenD -- KenD From ume at blueplane.jp Sat Oct 17 00:28:23 2015 From: ume at blueplane.jp (Masashi UMEZAWA) Date: Sat, 17 Oct 2015 14:28:23 +0900 Subject: [Cuis] veryShortName In-Reply-To: <20151012080516.9224a7578af856399be5679f@Whidbey.com> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Message-ID: Hi all, Actually I sometimes uses #shortName for selecting package name part from MCZ files (package.123.mcz). In this case, package name part is not prefix. But #shortName is not so clear, neither. Perhaps #firstName or #nameUpToDot would be better? Best regards, 2015-10-13 0:05 GMT+09:00 KenD : > Greetings, > > I have been looking at FileMan and had some confusion with #FmFileEntry>>shortName. > > 'this.that.txt' asFileEntry name. ==> 'this.that.txt' > 'this.that.txt' asFileEntry shortName. ==> 'this' > > I expected #shortName to answer the same result as baseName. > > 'this.that.txt' asFileEntry baseName. ==> 'this.that' > > I find the current behavior confusing. Is there a real need to have #shortName differ from #baseName? > > If the current #shortName behavior is required, could the name be changed to something nore mnemonic. Perhaps #firstPrefix ? > > Thanks much, > -KenD > > > > > -- > KenD -- [:masashi | ^umezawa] From Ken.Dickey at Whidbey.com Sat Oct 17 09:39:32 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sat, 17 Oct 2015 07:39:32 -0700 Subject: [Cuis] veryShortName In-Reply-To: References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Message-ID: <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> On Sat, 17 Oct 2015 14:28:23 +0900 Masashi UMEZAWA wrote: > Perhaps #firstName or #nameUpToDot would be better? Yes. Either works for me. Thanks, KenD From dnorton at mindspring.com Tue Oct 20 15:43:02 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 20 Oct 2015 16:43:02 -0400 Subject: [Cuis] PluggableListMorph Message-ID: <5626A756.25587.11E39F9@dnorton.mindspring.com> Greetings, PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be daunting because of the use of the dependency mechanism. AFAICT the tools do not display dependencies and even if they did, it's not clear why some of them exist. What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar that can be in the Terse Guide. It should show an example of selection in one list causing the population of another list and selection in that list causing the population of some other morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a method sends #changed: with a parameter referring to another method - why? The design needs to be explained. - Dan From Ken.Dickey at Whidbey.com Thu Oct 22 17:39:04 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Thu, 22 Oct 2015 15:39:04 -0700 Subject: [Cuis] PluggableListMorph In-Reply-To: <5626A756.25587.11E39F9@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com> Message-ID: <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> On Tue, 20 Oct 2015 16:43:02 -0400 "Dan Norton" wrote: > PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be > daunting because of the use of the dependency mechanism. AFAICT the tools do not display > dependencies and even if they did, it's not clear why some of them exist. > > What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar > that can be in the Terse Guide. It should show an example of selection in one list causing the > population of another list and selection in that list causing the population of some other > morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a > method sends #changed: with a parameter referring to another method - why? The design > needs to be explained. Dan, +1 A tool to detect/show such "out of band" control/change linkages/dependencies would be most welcomed, as would a Principles of Operation. Taking a quick look at my own code ("guilty as charged, sir") >> grep "changed:" */*.st Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! ! Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #actualContents! ! Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. I see two cases where one wants to be notified of changes without adding specific code to individual morph instances. In each case one wants to propagate updates to dependent views. [1] Change in internal Morph state should update viewers onto that state. [2] The special case of selection change in a list (PlugableListMorph) should update dependent viewers. So the simple explanation for "WHY change notification" is to update (perhaps multiple) viewers without doing special notification code in the Morphs being viewed. The target Morph should not have to know how many, if any, views onto its state exist. HOW is the registration process: Class ActiveModel and its subclass: SystemChangeNotifier I am a rare user of the change notification mechanism and would also benefit from good documentation and better tool(s) in this area. Cheers, KenD From dnorton at mindspring.com Fri Oct 23 10:56:26 2015 From: dnorton at mindspring.com (Dan Norton) Date: Fri, 23 Oct 2015 11:56:26 -0400 Subject: [Cuis] PluggableListMorph In-Reply-To: <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> Message-ID: <562A58AA.15972.4E08E7@dnorton.mindspring.com> On 22 Oct 2015 at 15:39, KenD wrote: > On Tue, 20 Oct 2015 16:43:02 -0400 > "Dan Norton" wrote: > > > PluggableListMorph has valuable behavior but applying it in morphs > with multiple lists can be > > daunting because of the use of the dependency mechanism. AFAICT > the tools do not display > > dependencies and even if they did, it's not clear why some of them > exist. > > > > What is needed is a "PluggableListMorph Principles of Operation" > doc, or something similar > > that can be in the Terse Guide. It should show an example of > selection in one list causing the > > population of another list and selection in that list causing the > population of some other > > morph. Isn't that like FileList? Yes, but we need the whys and > wherefors. For example, a > > method sends #changed: with a parameter referring to another > method - why? The design > > needs to be explained. > > Dan, > > +1 > > A tool to detect/show such "out of band" control/change > linkages/dependencies would be most welcomed, as would a Principles > of Operation. > > Taking a quick look at my own code ("guilty as charged, sir") > > >> grep "changed:" */*.st > Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph > Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! > ! > Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. > Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > #actualContents! ! > Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. > Hi Ken, In #actualContents: there is "self changed: #actualContents" which seems reasonable. However, in #refetch there is "self changed: #refetch" which is perplexing because it looks like infinite recursion, but it must be OK because similar examples appear in Browser. - Dan From juan at jvuletich.org Fri Oct 23 11:31:51 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 13:31:51 -0300 Subject: [Cuis] PluggableListMorph In-Reply-To: <5626A756.25587.11E39F9@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com> Message-ID: <562A60F7.1070702@jvuletich.org> Hi Dan, On 20/10/2015 05:43 p.m., Dan Norton wrote: > Greetings, > > PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be > daunting because of the use of the dependency mechanism. AFAICT the tools do not display > dependencies and even if they did, it's not clear why some of them exist. Yes. Most tools are still using the changed:/update: dependency mechanism that comes from MVC in Smalltalk-80. Later, Squeak and Cuis also included the #when:send:to: event system. It should replace changed:/update: in all client code because it helps produce code that is easier to understand. This is something we should do at some moment. > What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar > that can be in the Terse Guide. It should show an example of selection in one list causing the > population of another list and selection in that list causing the population of some other > morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a > method sends #changed: with a parameter referring to another method - why? The design > needs to be explained. > > - Dan Most likely all the classic references apply (In the blue book? Or most likely in Inside Smalltalk vol II). I'm sure there are others. Including excepts and/or references to them in TerseGuide would indeed be great. Please also keep in mind that this is not only for lists. It is essentially the same mechanism used for text panes, buttons, lists, tree lists, etc. Thanks, Juan Vuletich From juan at jvuletich.org Fri Oct 23 11:59:43 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 13:59:43 -0300 Subject: [Cuis] PluggableListMorph In-Reply-To: <562A58AA.15972.4E08E7@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> <562A58AA.15972.4E08E7@dnorton.mindspring.com> Message-ID: <562A677F.50500@jvuletich.org> On 23/10/2015 12:56 p.m., Dan Norton wrote: > On 22 Oct 2015 at 15:39, KenD wrote: > >> On Tue, 20 Oct 2015 16:43:02 -0400 >> "Dan Norton" wrote: >> >>> PluggableListMorph has valuable behavior but applying it in morphs >> with multiple lists can be >>> daunting because of the use of the dependency mechanism. AFAICT >> the tools do not display >>> dependencies and even if they did, it's not clear why some of them >> exist. >>> What is needed is a "PluggableListMorph Principles of Operation" >> doc, or something similar >>> that can be in the Terse Guide. It should show an example of >> selection in one list causing the >>> population of another list and selection in that list causing the >> population of some other >>> morph. Isn't that like FileList? Yes, but we need the whys and >> wherefors. For example, a >>> method sends #changed: with a parameter referring to another >> method - why? The design >>> needs to be explained. >> Dan, >> >> +1 >> >> A tool to detect/show such "out of band" control/change >> linkages/dependencies would be most welcomed, as would a Principles >> of Operation. >> >> Taking a quick look at my own code ("guilty as charged, sir") >> >>>> grep "changed:" */*.st >> Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! >> ! >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: >> #actualContents! ! >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. >> > Hi Ken, > > In #actualContents: there is "self changed: #actualContents" which seems reasonable. > > However, in #refetch there is "self changed: #refetch" which is perplexing because it looks > like infinite recursion, but it must be OK because similar examples appear in Browser. > > - Dan Just look at senders of #refetched . (not refetch!) It is quite simple, actually. To see a bit more on how lists are used, see references to PluggableListMorph. The second is #buildMorphicMessageCatList. See how it parametrizes the instance it builds. These methods that create various lists are quite similar, and all they do is to bind each list with a different aspect of the model. In this case, with #messageCategoryList. See implementors and senders. It is clear that the implementors are methods in models that answer (guess what!!!!) a list of message categories. When you look at senders senders, you can see that some are in the model, doing things like 'self changed: #messageCategoryList'. It is easy to see that this means that the list of message categories have changed, and anybody depending on that should update itself. Now we have a detail that is not that obvious, and most likely the clue you need to understand this all. See implementors of #update: in PluggableListMorph and the other PluggableMorph classes. #update: compares the argument with the listGetter (or the appropriate ivar for each morph). So, when the model does 'self changed: #messageCategoryList', all dependent morphs get message 'eachMorph update: #messageCategoryList'. And only those morphs that were configured to watch on this symbol with react. As I said before, this is the changed/update mechanism in MVC in Smalltlk-80. Using #when:send:to: insted would lead to better code. But documenting the current state of the system is needed and important, Cheers, Juan Vuletich From juan at jvuletich.org Fri Oct 23 12:22:19 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 14:22:19 -0300 Subject: [Cuis] veryShortName In-Reply-To: <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> Message-ID: <562A6CCB.6000603@jvuletich.org> On 17/10/2015 11:39 a.m., KenD wrote: > On Sat, 17 Oct 2015 14:28:23 +0900 > Masashi UMEZAWA wrote: > >> Perhaps #firstName or #nameUpToDot would be better? > Yes. Either works for me. > > Thanks, > KenD > Besides #shortName, we also have #splitNameVersionExtensionFor:, #baseNameFor:, #baseName, etc. Reducing their number would be good. As it would be to separate those that give a "standard service" from those that just solve a more specific need of some client code. Cheers, Juan Vuletich From juan at jvuletich.org Fri Oct 23 13:49:15 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 15:49:15 -0300 Subject: [Cuis] New Commit: FileMan adoption and tweaks Message-ID: <562A812B.7090101@jvuletich.org> Hi Folks, I've just updated github. I did many changes, to adopt FileMan almost everywhere in Cuis and core packages.I did a few changes to FileMan and the API. The one you might notice is that I've made FmFileEntry and FmDirectoryEntry siblings, under a new FmEntry. Now, each class is more specific: FmFileEntry doesn't handle Directory responsibilities (like creating files in it) and FmDirectoryEntry doesn't support File responsibility (like creating a FileStream on itself). I think it is much cleaner this way. The change you might need to care about is that 'dirName' asDirectoryEntry / 'subdir' answers an FmDirectoryEntry and the new #//: 'dirName' asDirectoryEntry // 'filename' answers an FmFileEntry. Please adapt your packages to the new FileMan API, as the old FileDirectory hierarchy will be deprecated soon, and later removed from Cuis. Oh, this commit also includes new versions of TerseGuide and ClassCommentBrowser by Dan Norton. (Thanks Dan!) Cheers, Juan Vuletich From pbpublist at gmail.com Fri Oct 23 16:10:42 2015 From: pbpublist at gmail.com (Phil (list)) Date: Fri, 23 Oct 2015 17:10:42 -0400 Subject: [Cuis] Effect of Cursor Movement In-Reply-To: <55F307E2.4040706@jvuletich.org> References: <55F2FF07.16923.7339F5@dnorton.mindspring.com> <55F307E2.4040706@jvuletich.org> Message-ID: <1445634642.3451.6.camel@gmail.com> On Fri, 2015-09-11 at 13:57 -0300, Juan Vuletich wrote: > Hi Dan, > > (below) > On 9/11/2015 1:19 PM, Dan Norton wrote: > > Hello, > > > > To see this, Bring up BouncingAtomsMorph, enlarge the window, set a > > high atoms count so > > that you can easily sense atom movement. > > > > Notice how movement speeds up when the cursor is moved and slows > > when it stops? Turn > > on FPS. On my machine, frame rate is about 22 with no cursor > > movement and increases to > > around 36 when the cursor is moving. The cursor does not have to be > > in the window. It can > > be anywhere. > > > > Why should that be? It may not be a problem, but it is a curiosity. > > Any explanation? > > > > BTW this is Win7, cogwin-15.33.3427, Cuis 2478. > > > > ? - Dan > > Haven't even taken a look, so if I did maybe I would find something > else... but for sure Cuis is triggering MouseMoveEvents, and looking > for > possible interested parties. That, on each Morphic cycle. So, each > Morphic cycle might take a bit longer, and FPS can go a bit down. > > In any case, if you are curious, you can take a closer look. Often, > questions like this lead to possible optimizations! > The issue he's describing sounds like the opposite of that. ?Any chance this is related to the issue we discussed on vm-dev back in 2012? (The thread was titled "Cog VM idling performance") ?Your fix back then mostly addressed the issue (I've noticed some minor idling slowdowns since then, but nothing as extreme as when I originally reported the issue) Funny thing is I think I'm now dealing with the other side of this problem in Seaside: I have a situation where an idling VM is consuming too much CPU... (nothing specifically related to Cuis other than the warning to 'be careful of what you wish for' :-) > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org From dnorton at mindspring.com Fri Oct 23 18:04:27 2015 From: dnorton at mindspring.com (Dan Norton) Date: Fri, 23 Oct 2015 19:04:27 -0400 Subject: [Cuis] PluggableListMorph In-Reply-To: <562A677F.50500@jvuletich.org> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <562A58AA.15972.4E08E7@dnorton.mindspring.com>, <562A677F.50500@jvuletich.org> Message-ID: <562ABCFB.20558.1D5E5B6@dnorton.mindspring.com> On 23 Oct 2015 at 13:59, Juan Vuletich wrote: > On 23/10/2015 12:56 p.m., Dan Norton wrote: > > On 22 Oct 2015 at 15:39, KenD wrote: > > > >> On Tue, 20 Oct 2015 16:43:02 -0400 > >> "Dan Norton" wrote: > >> > >>> PluggableListMorph has valuable behavior but applying it in > morphs > >> with multiple lists can be > >>> daunting because of the use of the dependency mechanism. > AFAICT > >> the tools do not display > >>> dependencies and even if they did, it's not clear why some of > them > >> exist. > >>> What is needed is a "PluggableListMorph Principles of > Operation" > >> doc, or something similar > >>> that can be in the Terse Guide. It should show an example of > >> selection in one list causing the > >>> population of another list and selection in that list causing > the > >> population of some other > >>> morph. Isn't that like FileList? Yes, but we need the whys and > >> wherefors. For example, a > >>> method sends #changed: with a parameter referring to another > >> method - why? The design > >>> needs to be explained. > >> Dan, > >> > >> +1 > >> > >> A tool to detect/show such "out of band" control/change > >> linkages/dependencies would be most welcomed, as would a > Principles > >> of Operation. > >> > >> Taking a quick look at my own code ("guilty as charged, sir") > >> > >>>> grep "changed:" */*.st > >> Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph > >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: > #actualContents! > >> ! > >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. > >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > >> #actualContents! ! > >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > #refetched. > >> > > Hi Ken, > > > > In #actualContents: there is "self changed: #actualContents" which > seems reasonable. > > > > However, in #refetch there is "self changed: #refetch" which is > perplexing because it looks > > like infinite recursion, but it must be OK because similar > examples appear in Browser. > > > > - Dan > > Just look at senders of #refetched . (not refetch!) It is quite > simple, > actually. > > To see a bit more on how lists are used, see references to > PluggableListMorph. The second is #buildMorphicMessageCatList. See > how > it parametrizes the instance it builds. These methods that create > various lists are quite similar, and all they do is to bind each > list > with a different aspect of the model. In this case, with > #messageCategoryList. See implementors and senders. It is clear that > the > implementors are methods in models that answer (guess what!!!!) a > list > of message categories. When you look at senders senders, you can see > that some are in the model, doing things like 'self changed: > #messageCategoryList'. It is easy to see that this means that the > list > of message categories have changed, and anybody depending on that > should > update itself. > > Now we have a detail that is not that obvious, and most likely the > clue > you need to understand this all. See implementors of #update: in > PluggableListMorph and the other PluggableMorph classes. #update: > compares the argument with the listGetter (or the appropriate ivar > for > each morph). So, when the model does 'self changed: > #messageCategoryList', all dependent morphs get message 'eachMorph > update: #messageCategoryList'. And only those morphs that were > configured to watch on this symbol with react. > > As I said before, this is the changed/update mechanism in MVC in > Smalltlk-80. Ah. That's the key - I haven't looked at MVC in years. The model need not know about any view. It is the dependee, signalling happenings that the dependents might like to know. What dependents do starts with their #update: message which may take action after looking at the parameter (or not). The views are dependents of the model. It's misleading when parameters of #changed: look just like message selectors in the model. It gives the impression that those messages are to be sent or invoked, when all that's necessary is that the parameter be understood by the model. That is why it looks like infinite recursion when a method says: refetched ... self changed: #refetched. Far better if the parameter was "foobar or #putDataInTheTextMorphs or the like. > Using #when:send:to: insted would lead to better code. I will definitely start doing that. > But > documenting the current state of the system is needed and > important, With this insight, I may be able to do that now. - Dan From Ken.Dickey at Whidbey.com Fri Oct 23 22:50:16 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Fri, 23 Oct 2015 20:50:16 -0700 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <562A812B.7090101@jvuletich.org> References: <562A812B.7090101@jvuletich.org> Message-ID: <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> On Fri, 23 Oct 2015 15:49:15 -0300 Juan Vuletich wrote: > Hi Folks, > > I've just updated github. I did many changes, to adopt FileMan almost > everywhere in Cuis and core packages. You might want to update: SystemDictionary>>openSourcesAndChanges BTW, I was using String>>upToLastPathSeparator Any chance of getting it back? Cheers, -KenD -------------- next part -------------- A non-text attachment was scrubbed... Name: invoke.out Type: application/octet-stream Size: 3041 bytes Desc: not available URL: From ume at blueplane.jp Sun Oct 25 09:15:18 2015 From: ume at blueplane.jp (Masashi UMEZAWA) Date: Sun, 25 Oct 2015 23:15:18 +0900 Subject: [Cuis] veryShortName In-Reply-To: <562A6CCB.6000603@jvuletich.org> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> <562A6CCB.6000603@jvuletich.org> Message-ID: Hi all, Indeed, we should avoid adding ad-hoc methods. Currently I'm thinking to introduce a more generic API (splitName:by:) to FmFileIOAccessor. So we can implement FmFileEntry methods more consistently like: FmFileEntry >> firstName ^ (self fileAccessor splitName: self name by: self extensionDelimiter) first FmFileEntry >> extension ^ (self fileAccessor splitName: self name by: self extensionDelimiter) last FmFileEntry >> baseName | names | names := self fileAccessor splitName: self name by: self extensionDelimiter. names size = 1 ifTrue: [^names first]. ^self extensionDelimiter join: names allButLast Best regards, 2015-10-24 2:22 GMT+09:00 Juan Vuletich : > On 17/10/2015 11:39 a.m., KenD wrote: >> >> On Sat, 17 Oct 2015 14:28:23 +0900 >> Masashi UMEZAWA wrote: >> >>> Perhaps #firstName or #nameUpToDot would be better? >> >> Yes. Either works for me. >> >> Thanks, >> KenD >> > > Besides #shortName, we also have #splitNameVersionExtensionFor:, > #baseNameFor:, #baseName, etc. Reducing their number would be good. As it > would be to separate those that give a "standard service" from those that > just solve a more specific need of some client code. > > Cheers, > Juan Vuletich -- [:masashi | ^umezawa] From pavel.krivanek at gmail.com Sun Oct 25 10:36:09 2015 From: pavel.krivanek at gmail.com (Pavel Krivanek) Date: Sun, 25 Oct 2015 16:36:09 +0100 Subject: [Cuis] smallest Cuis image with Morphic Message-ID: Hi, is there the old minimal Cuis image (about 2MB with Morphic) still somewhere to download? Cheers, -- Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Sun Oct 25 11:19:38 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sun, 25 Oct 2015 09:19:38 -0700 Subject: [Cuis] veryShortName In-Reply-To: References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> <562A6CCB.6000603@jvuletich.org> Message-ID: <20151025091938.1f28b5c26bb7cdbb5d462c6c@Whidbey.com> On Sun, 25 Oct 2015 23:15:18 +0900 Masashi UMEZAWA wrote: > Currently I'm thinking to introduce a more generic API (splitName:by:) > to FmFileIOAccessor. That would be great! Juan, would you let me know when this is integrated? I/we need to update/replace StandardFileMenu. Thanks much, -KenD From 0800nacho at gmail.com Sun Oct 25 13:03:27 2015 From: 0800nacho at gmail.com (nacho) Date: Sun, 25 Oct 2015 11:03:27 -0700 (PDT) Subject: [Cuis] Changing Wallpaper Message-ID: <1445796207751-4857882.post@n4.nabble.com> Hi Folks, I know how to take out the default Cuis wallpaper and change it with a solid color. However, I'm not able to use another image. What are the steps needed to get this done? Thanks in advance Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Sun Oct 25 17:11:26 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Sun, 25 Oct 2015 19:11:26 -0300 Subject: [Cuis] smallest Cuis image with Morphic In-Reply-To: References: Message-ID: <562D538E.5090406@jvuletich.org> On 25/10/2015 12:36 p.m., Pavel Krivanek wrote: > Hi, > > is there the old minimal Cuis image (about 2MB with Morphic) still > somewhere to download? > > Cheers, > -- Pavel > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org Hi Pavel, Yes. It is still at www.jvuletich.org/Cuis/Cuis3.1r3.zip . You'll need a sources file. You can get it from www.jvuletich.org/Cuis/Cuis3.1-0850.zip . Please note that it is possible to build such a small image from a current Cuis, if desired. Cheers, Juan Vuletich Ps. I'm sure you're on something interesting with this. Could you please tell a bit? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Sun Oct 25 17:56:31 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sun, 25 Oct 2015 15:56:31 -0700 Subject: [Cuis] smallest Cuis image with Morphic In-Reply-To: <562D538E.5090406@jvuletich.org> References: <562D538E.5090406@jvuletich.org> Message-ID: <20151025155631.e9f696d0b85c0bcff578f5ed@Whidbey.com> On Sun, 25 Oct 2015 19:11:26 -0300 Juan Vuletich wrote: .. > Please note that it is possible to build such a small image from a > current Cuis, if desired. BTW, I tried Smalltalk reduceCuis. in 2555 but it seems to go into a loop at AnObsoleteUnixFileDirectory class(FileDirectory class)>>pathDelimiter Smalltalk reduceCuis. is successful under 2528 and produces 4.8 Mb image FYI, -KenD From dnorton at mindspring.com Mon Oct 26 15:58:12 2015 From: dnorton at mindspring.com (Dan Norton) Date: Mon, 26 Oct 2015 16:58:12 -0400 Subject: [Cuis] PluggableListMorph Message-ID: <562E93E4.6994.128E352@dnorton.mindspring.com> Hello All, Please review the following for accuracy. It's not complete. It's a start on a "Principles of Operation" for applying PluggableListMorph for fun and profit. Maybe it should be called "PluggableListMorph for Dummies". I'm especially interested in whether you agree with the "coincidental" statement. PluggableListMorph is designed to work as part of one or more views on a model in the MVC paradigm (Note 1). The model is not directly aware of the existence of any view; instead, it signals changes in itself by broadcasting symbols with the #changed: method. In this way, any view which is related to the model can detect the changes by examining the symbol in its #update: method. Thus while the model is not explicitly aware of a view, there is an implicit relationship in that a view must know the significance of the symbols broadcast by the model in order to respond appropriately. Views are dependents of a model and therefore the model is a sponsor of views. Use of the #changed: and #update: methods is the essence of the Smalltalk dependency mechanism (Inside II). The model sends #changed: and as a result, all dependents (e.g. views) on it receive #update:. In the #update: method, the view examines the symbol and decides what, if anything, to do. While the symbol is, in practice, often identical to the name of a method, this is coincidental and unfortunately a source of confusion and misdirection. Note 1. The MVC paradigm is mentioned here for historical context. PluggableListMorph can also be employed in other design schemes. Inside II. LaLonde and Pugh, "Inside Smalltalk, Volume II" Thanks, - Dan From Ken.Dickey at Whidbey.com Mon Oct 26 17:39:42 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Mon, 26 Oct 2015 15:39:42 -0700 Subject: [Cuis] PluggableListMorph In-Reply-To: <562E93E4.6994.128E352@dnorton.mindspring.com> References: <562E93E4.6994.128E352@dnorton.mindspring.com> Message-ID: <20151026153942.aebae2c125a712e22f4b9fa6@Whidbey.com> Hi Dan, Good explanation. I like good explanations. 8) You might be interested in the code examples in: http://stackoverflow.com/questions/17082576/implementing-the-observer-pattern-in-smalltalk-visualworks I would note that the observer pattern discussion might be better served by the more modern #when:send:to: idiom. [E.g. look at when:send:to: senders; Check the TaskBar for simple usage]. In particular, an observer can register for event updates and get a specific message. IMHO we should rewrite PluggableListMorph to use when:send:to: $0.02 -KenD From 0800nacho at gmail.com Tue Oct 27 10:02:53 2015 From: 0800nacho at gmail.com (nacho) Date: Tue, 27 Oct 2015 08:02:53 -0700 (PDT) Subject: [Cuis] Changing Wallpaper In-Reply-To: <1445796207751-4857882.post@n4.nabble.com> References: <1445796207751-4857882.post@n4.nabble.com> Message-ID: <1445958173832-4858215.post@n4.nabble.com> It seems that I have to convert the image as an array, isn't it? ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882p4858215.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From dnorton at mindspring.com Tue Oct 27 10:23:49 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 27 Oct 2015 11:23:49 -0400 Subject: [Cuis] Could Not Find Feature Requirement Message-ID: <562F9705.519.430ADA@dnorton.mindspring.com> Cuis4.2-2528 successfully loads a package with a feature requirement. With Cuis4.2-2555, loading the same package gets: Error:Could not find package supplying feature: FeatureRequirement(Records 1.15 to *.*) - Dan From hannes.hirzel at gmail.com Tue Oct 27 11:27:58 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue, 27 Oct 2015 17:27:58 +0100 Subject: [Cuis] Changing Wallpaper In-Reply-To: <1445958173832-4858215.post@n4.nabble.com> References: <1445796207751-4857882.post@n4.nabble.com> <1445958173832-4858215.post@n4.nabble.com> Message-ID: Have a look at PasteUpMorph >> backgroundImageData: aByteArray Then do something like | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: (FileStream readOnlyFileNamed: filename) binary contentsOfEntireFile. HTH --Hannes On 10/27/15, nacho <0800nacho at gmail.com> wrote: > It seems that I have to convert the image as an array, isn't it? > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/Changing-Wallpaper-tp4857882p4858215.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From dnorton at mindspring.com Tue Oct 27 13:04:10 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 27 Oct 2015 14:04:10 -0400 Subject: [Cuis] Could Not Find Feature Requirement Message-ID: <562FBC9A.2992.D5D887@dnorton.mindspring.com> If a copy of the required feature is placed in the directory of the image, the package loads successfully, - Dan From 0800nacho at gmail.com Tue Oct 27 15:29:37 2015 From: 0800nacho at gmail.com (nacho) Date: Tue, 27 Oct 2015 13:29:37 -0700 (PDT) Subject: [Cuis] Changing Wallpaper In-Reply-To: References: <1445796207751-4857882.post@n4.nabble.com> <1445958173832-4858215.post@n4.nabble.com> Message-ID: <1445977777218-4858263.post@n4.nabble.com> Thank you !!! That worked perfectly!! ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882p4858263.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Wed Oct 28 09:14:57 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:14:57 -0300 Subject: [Cuis] Effect of Cursor Movement In-Reply-To: <1445634642.3451.6.camel@gmail.com> References: <55F2FF07.16923.7339F5@dnorton.mindspring.com> <55F307E2.4040706@jvuletich.org> <1445634642.3451.6.camel@gmail.com> Message-ID: <5630D861.2090509@jvuletich.org> Hi Folks, (inline) On 10/23/2015 6:10 PM, Phil (list) wrote: > On Fri, 2015-09-11 at 13:57 -0300, Juan Vuletich wrote: >> Hi Dan, >> >> (below) >> On 9/11/2015 1:19 PM, Dan Norton wrote: >>> Hello, >>> >>> To see this, Bring up BouncingAtomsMorph, enlarge the window, set a >>> high atoms count so >>> that you can easily sense atom movement. >>> >>> Notice how movement speeds up when the cursor is moved and slows >>> when it stops? Turn >>> on FPS. On my machine, frame rate is about 22 with no cursor >>> movement and increases to >>> around 36 when the cursor is moving. The cursor does not have to be >>> in the window. It can >>> be anywhere. >>> >>> Why should that be? It may not be a problem, but it is a curiosity. >>> Any explanation? >>> >>> BTW this is Win7, cogwin-15.33.3427, Cuis 2478. >>> >>> - Dan >> Haven't even taken a look, so if I did maybe I would find something >> else... but for sure Cuis is triggering MouseMoveEvents, and looking >> for >> possible interested parties. That, on each Morphic cycle. So, each >> Morphic cycle might take a bit longer, and FPS can go a bit down. >> >> In any case, if you are curious, you can take a closer look. Often, >> questions like this lead to possible optimizations! >> > The issue he's describing sounds like the opposite of that. Any chance > this is related to the issue we discussed on vm-dev back in 2012? (The > thread was titled "Cog VM idling performance") Your fix back then > mostly addressed the issue (I've noticed some minor idling slowdowns > since then, but nothing as extreme as when I originally reported the > issue) Thanks for the heads-up. You are right. The issue is related to that code. I fixed it, and now BouncingAtomsMorph fps is quite better and independent of user activity! > Funny thing is I think I'm now dealing with the other side of this > problem in Seaside: I have a situation where an idling VM is consuming > too much CPU... (nothing specifically related to Cuis other than the > warning to 'be careful of what you wish for' :-) Check for #serverMode. This sould fix that problem. You can tweak it to devote very little cpu to Morphic (with sluggish Morphic when you need it). Squeak also has it. Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:16:14 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:16:14 -0300 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> Message-ID: <5630D8AE.8030803@jvuletich.org> Hi Ken, On 10/24/2015 12:50 AM, KenD wrote: > On Fri, 23 Oct 2015 15:49:15 -0300 > Juan Vuletich wrote: > >> Hi Folks, >> >> I've just updated github. I did many changes, to adopt FileMan almost >> everywhere in Cuis and core packages. > You might want to update: > SystemDictionary>>openSourcesAndChanges Of course. Done. I've just commited an image that no longer includes FileDirectory!!! > BTW, I was using String>>upToLastPathSeparator > > Any chance of getting it back? Sure. Added it back. > Cheers, > -KenD Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:19:05 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:19:05 -0300 Subject: [Cuis] Could Not Find Feature Requirement In-Reply-To: <562F9705.519.430ADA@dnorton.mindspring.com> References: <562F9705.519.430ADA@dnorton.mindspring.com> Message-ID: <5630D959.5040903@jvuletich.org> On 10/27/2015 12:23 PM, Dan Norton wrote: > Cuis4.2-2528 successfully loads a package with a feature requirement. > > With Cuis4.2-2555, loading the same package gets: > > Error:Could not find package supplying feature: FeatureRequirement(Records 1.15 to *.*) > > - Dan > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > Please try with the latest image. If you still have problems, give details about the directory structure that makes it fail. Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:55:12 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:55:12 -0300 Subject: [Cuis] New Commit: FileDirectory finally gone! Message-ID: <5630E1D0.7070907@jvuletich.org> Hi Folks, I finished the migration to FileMan. I removed the FileDirectory and DirectoryEntry hierarchies. I also removed a few rather ambiguous creation methods in StandardFileStream. Please update your packages and code accordingly. FileMan is so much nicer to use! Especially, prefer #writeStream: and #readStream: methods, that do the close for you (even in the presence of errors, etc). There might be details that still need tweaking. Let's go into a stabilization phase with this. When we are all happy, we can call it Cuis 5.0. Cuis keeps showing us that constant cleaning and simplification enables this kind of deep changes and evolution. This is so much better than simply adding yet-another-API-for-doing-the-same-thing, as other Smalltalk environments are forced to do! Cheers, Juan Vuletich From garduino at gmail.com Wed Oct 28 10:25:45 2015 From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=) Date: Wed, 28 Oct 2015 12:25:45 -0300 Subject: [Cuis] New Commit: FileDirectory finally gone! In-Reply-To: <5630E1D0.7070907@jvuletich.org> References: <5630E1D0.7070907@jvuletich.org> Message-ID: +1 ! Saludos / Regards, Germ?n Arduino @garduino 2015-10-28 11:55 GMT-03:00 Juan Vuletich : > Hi Folks, > > I finished the migration to FileMan. I removed the FileDirectory and > DirectoryEntry hierarchies. I also removed a few rather ambiguous creation > methods in StandardFileStream. Please update your packages and code > accordingly. FileMan is so much nicer to use! Especially, prefer > #writeStream: and #readStream: methods, that do the close for you (even in > the presence of errors, etc). > > There might be details that still need tweaking. Let's go into a > stabilization phase with this. When we are all happy, we can call it Cuis > 5.0. > > Cuis keeps showing us that constant cleaning and simplification enables > this kind of deep changes and evolution. This is so much better than simply > adding yet-another-API-for-doing-the-same-thing, as other Smalltalk > environments are forced to do! > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Wed Oct 28 11:05:34 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Wed, 28 Oct 2015 09:05:34 -0700 Subject: [Cuis] New Commit: FileDirectory finally gone! In-Reply-To: <5630E1D0.7070907@jvuletich.org> References: <5630E1D0.7070907@jvuletich.org> Message-ID: <20151028090534.bdade822ea0f0e0ca2739444@Whidbey.com> On Wed, 28 Oct 2015 11:55:12 -0300 Juan Vuletich wrote: > There might be details that still need tweaking. Let's go into a > stabilization phase with this. When we are all happy, we can call it > Cuis 5.0. WooHoo! 8^) > Cuis keeps showing us that constant cleaning and simplification enables > this kind of deep changes and evolution. This is so much better than > simply adding yet-another-API-for-doing-the-same-thing, as other > Smalltalk environments are forced to do! Just tries Solitaire and noted it is significant faster. Current Class count is 504. Juan, you have much to be proud about. Thanks once again for Cuis!!! -- -KenD ================ count := 0. Metaclass allInstancesDo: [ :ignore | count := count + 1 ]. count. "==> 504" ================ From dnorton at mindspring.com Wed Oct 28 13:29:13 2015 From: dnorton at mindspring.com (Dan Norton) Date: Wed, 28 Oct 2015 14:29:13 -0400 Subject: [Cuis] Could Not Find Feature Requirement In-Reply-To: <5630D959.5040903@jvuletich.org> References: <562F9705.519.430ADA@dnorton.mindspring.com>, <5630D959.5040903@jvuletich.org> Message-ID: <563113F9.4492.E99BF5@dnorton.mindspring.com> On 28 Oct 2015 at 11:19, Juan Vuletich wrote: > On 10/27/2015 12:23 PM, Dan Norton wrote: > > Cuis4.2-2528 successfully loads a package with a feature > requirement. > > > > With Cuis4.2-2555, loading the same package gets: > > > > Error:Could not find package supplying feature: > FeatureRequirement(Records 1.15 to *.*) > > > > - Dan > > > > _______________________________________________ > > Cuis mailing list > > Cuis at jvuletich.org > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > Please try with the latest image. If you still have problems, give > details about the directory structure that makes it fail. > Hi Juan, You fixed it in Cuis4.2-2563! Thanks much! - Dan From 0800nacho at gmail.com Wed Oct 28 14:18:55 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 12:18:55 -0700 (PDT) Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <5630D8AE.8030803@jvuletich.org> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> Message-ID: <1446059935002-4858359.post@n4.nabble.com> So now, for importing a new wallpaper, instead of doing: | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: (FileStream readOnlyFileNamed: filename) binary contentsOfEntireFile. What Class and method should I use? Because FileStream>>readOnlyFileNamed: is no longer there. thanks in advance! nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From hannes.hirzel at gmail.com Wed Oct 28 16:38:18 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Wed, 28 Oct 2015 22:38:18 +0100 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <1446059935002-4858359.post@n4.nabble.com> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: filename asFileEntry binaryContents. On 10/28/15, nacho <0800nacho at gmail.com> wrote: > So now, for importing a new wallpaper, instead of doing: > > | filename | > filename _ 'Pluto.png'. > self runningWorld backgroundImageData: > (FileStream readOnlyFileNamed: filename) binary > contentsOfEntireFile. > > What Class and method should I use? Because FileStream>>readOnlyFileNamed: > is no longer there. > thanks in advance! > nacho > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From hannes.hirzel at gmail.com Wed Oct 28 16:50:32 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Wed, 28 Oct 2015 22:50:32 +0100 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: N.B. Have a look at the class comment of FmFileEntry and the seven example methods on the class side. And String>>asFileEntry There is a need for an example for #binaryContents and #binaryContents: On 10/28/15, H. Hirzel wrote: > | filename | > filename _ 'Pluto.png'. > self runningWorld backgroundImageData: filename asFileEntry > binaryContents. > > > On 10/28/15, nacho <0800nacho at gmail.com> wrote: >> So now, for importing a new wallpaper, instead of doing: >> >> | filename | >> filename _ 'Pluto.png'. >> self runningWorld backgroundImageData: >> (FileStream readOnlyFileNamed: filename) binary >> contentsOfEntireFile. >> >> What Class and method should I use? Because >> FileStream>>readOnlyFileNamed: >> is no longer there. >> thanks in advance! >> nacho >> >> >> >> >> ----- >> Nacho >> Smalltalker apprentice. >> Buenos Aires, Argentina. >> -- >> View this message in context: >> http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html >> Sent from the Cuis Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Cuis mailing list >> Cuis at jvuletich.org >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> > From 0800nacho at gmail.com Wed Oct 28 17:53:05 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 15:53:05 -0700 (PDT) Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: <1446072785216-4858383.post@n4.nabble.com> Hannes, Thanks again so much! cheers Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858383.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From 0800nacho at gmail.com Wed Oct 28 18:26:28 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 16:26:28 -0700 (PDT) Subject: [Cuis] VM Crashing when loading Themes pkg Message-ID: <1446074788550-4858389.post@n4.nabble.com> I'm trying to load the themes pkg using the latest Cuis image and every time I try to do it the VM crashes. I was using the last Cog vm from Eliot's place. I tried using previous vms but the result is the same. I've tried with other packages and the effect is the same: vm crashes. I'm in OSX 10.11.1 I attach the crash.dmp file Could it be due to the changes in the FM? Anyone is having the same crashes? Thanks Nacho crash.dmp ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/VM-Crashing-when-loading-Themes-pkg-tp4858389.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Thu Oct 29 07:37:57 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Thu, 29 Oct 2015 09:37:57 -0300 Subject: [Cuis] VM Crashing when loading Themes pkg In-Reply-To: <1446074788550-4858389.post@n4.nabble.com> References: <1446074788550-4858389.post@n4.nabble.com> Message-ID: <56321325.6080504@jvuletich.org> Hi Nacho, Please use Cog #3370 as indicated in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/GettingStarted-UsingCommandline.md and other documentation there. Cheers, Juan Vuletich On 10/28/2015 8:26 PM, nacho wrote: > I'm trying to load the themes pkg using the latest Cuis image and every time > I try to do it the VM crashes. > I was using the last Cog vm from Eliot's place. I tried using previous vms > but the result is the same. > I've tried with other packages and the effect is the same: vm crashes. > I'm in OSX 10.11.1 > I attach the crash.dmp file > > Could it be due to the changes in the FM? > Anyone is having the same crashes? > Thanks > Nacho > > crash.dmp > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/VM-Crashing-when-loading-Themes-pkg-tp4858389.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From 0800nacho at gmail.com Thu Oct 29 07:52:39 2015 From: 0800nacho at gmail.com (nacho) Date: Thu, 29 Oct 2015 05:52:39 -0700 (PDT) Subject: [Cuis] VM Crashing when loading Themes pkg In-Reply-To: <56321325.6080504@jvuletich.org> References: <1446074788550-4858389.post@n4.nabble.com> <56321325.6080504@jvuletich.org> Message-ID: <1446123159957-4858467.post@n4.nabble.com> Thank you Juan! I tried a lot of vms but don't reached build 3370. And I should have read the documentation, sorry. best Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/VM-Crashing-when-loading-packages-tp4858389p4858467.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From Ken.Dickey at Whidbey.com Thu Oct 29 18:56:50 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Thu, 29 Oct 2015 16:56:50 -0700 Subject: [Cuis] ColorEditor updated Message-ID: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> Hi all, I updated Morphic-ColorEditor for simpler layout and font preferences updating. I also updated Morphic-Misc1 for font preferences update. Dan, note that the Morphic-ColorEditor uses #when:send:to: for updates. You can file it in and check senders. Bugs to /dev/null, er, I mean to me. ;^) Cheers, -KenD From 0800nacho at gmail.com Fri Oct 30 19:08:02 2015 From: 0800nacho at gmail.com (nacho) Date: Fri, 30 Oct 2015 17:08:02 -0700 (PDT) Subject: [Cuis] a simple method to change the wallpaper Message-ID: <1446250082444-4858760.post@n4.nabble.com> PasteUpMorph>>setBackgroundImage: aFilename "Sets the graphic file provided as a wallpaper" self runningWorld backgroundImageData: aFilename asFileEntry binaryContents. Then you go to the File List and copy the name of the file in the clipboard. Open a workspace: self runningWorld setBackgroundImage: '' screenshot.jpg ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/a-simple-method-to-change-the-wallpaper-tp4858760.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From dnorton at mindspring.com Sat Oct 31 21:01:06 2015 From: dnorton at mindspring.com (Dan Norton) Date: Sat, 31 Oct 2015 22:01:06 -0400 Subject: [Cuis] ColorEditor updated In-Reply-To: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> Message-ID: <56357262.9599.2DA3199@dnorton.mindspring.com> On 29 Oct 2015 at 16:56, KenD wrote: > Hi all, > > I updated Morphic-ColorEditor for simpler layout and font > preferences updating. > > I also updated Morphic-Misc1 for font preferences update. > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for > updates. You can file it in and check senders. > I've done that and I see that messages to SystemChangeNotifier are not required in order to use the method. Also, the dependency mechanism itself uses #when:send:to:. Any object can use #when:send:to: because it is an Object instance method. So, should this be named a different mechanism or is it just a different use of the dependency mechanism? If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#Featu reComparison - Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan at jvuletich.org Tue Oct 6 07:24:48 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Tue, 06 Oct 2015 09:24:48 -0300 Subject: [Cuis] Class Comment Browser In-Reply-To: <560C57DC.32345.163B7FF@dnorton.mindspring.com> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <4f00e132cd45e6e377ff945fafa610b0.squirrel@gator3294.hostgator.com> <560C57DC.32345.163B7FF@dnorton.mindspring.com> Message-ID: <5613BD90.4040204@jvuletich.org> Hi Dan, Apologies for the long delay in answering. I think you mean the text styler, that colorizes Smalltalk code, right? Well, an instance of InnerTextMorph might have a subinstance of SHTextStyler in the 'styler' variable. This is "Shout", originally from Squeak. But it might be disabled sometimes, as when the code pane is showing diffs, or bytecodes, etc. See #okToStyle , where the model is asked whether it is appropriate to style each time. If you can't solve the problem, point me to the latest version of CCB, and briefly describe steps, expected behavior, unwanted behavior (to be sure I understand), and I'll take a look. Cheers, Juan Vuletich On 30/09/2015 06:45 p.m., Dan Norton wrote: > Hi Juan, > > The editor class seems to remain constant as SmalltalkEditor. To see what is puzzling: > > open a browser on a class with an actual comment > view the class comment (? button) > select all of the comment and copy it > select, then deselect a message category > paste the comment in the code window as if defining a new method > see the difference in presentation > > What is making this switch? If I knew where this is done I might get the behavior I want in > CCB. > > - Dan > > On 30 Sep 2015 at 8:19, Juan Vuletich wrote: > >> Hi Dan, >> >> See the TextEditor hierarchy. See #editorClass, senders and >> implementors. >> It is the model who decides what kind of editor to use. >> >> An easy way to find out about this, is to realiza that what you want >> is >> the "Smalltalk Options" menu in code panes. Just write "Smalltalk >> Options" >> in some code pane, select it (without the quotes) and do right click >> / >> Smalltalk Options / Method Source with it. That leads you right to >> SmalltalkEditor. >> >> Cheers, >> Juan Vuletich >> >> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: >>> Hi Juan, >>> >>> >>> A little help, please. BrowserWindow uses >>> CodeWindow>>buildMorphicCodePane for the >>> class comment area. Although this area looks like text, >> expressions >>> appearing in class comments can be executed as in a workspace. >>> >>> I want the same behavior in Class Comment Browser, but all I get >> is text >>> behavior (no execution). How can this be changed? >>> >>> - Dan >>> >>> >>> _______________________________________________ >>> Cuis mailing list >>> Cuis at jvuletich.org >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >> >> _______________________________________________ >> Cuis mailing list >> Cuis at jvuletich.org >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From dnorton at mindspring.com Tue Oct 6 20:17:11 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 06 Oct 2015 21:17:11 -0400 Subject: [Cuis] Class Comment Browser In-Reply-To: <5613BD90.4040204@jvuletich.org> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <560C57DC.32345.163B7FF@dnorton.mindspring.com>, <5613BD90.4040204@jvuletich.org> Message-ID: <56147297.21959.20BF33E@dnorton.mindspring.com> Hi Juan, Delay? What delay? Not to worry :-) I regret that this problem is either beyond me or I'm blind to it. Had to clean up the act a bit because of all the fruitless experiments but the repo seems to behave OK. It is strongly desired by the (huge?) user community that the pane containing the comment would behave like a work space, e.g. allow statements to be executed and names to be highlighted and used to open a browser. The repo is: https://github.com/dhnorton/Cuis-Smalltalk-comments Please let me know what I need to do. - Dan On 6 Oct 2015 at 9:24, Juan Vuletich wrote: > Hi Dan, > > Apologies for the long delay in answering. > > I think you mean the text styler, that colorizes Smalltalk code, > right? > Well, an instance of InnerTextMorph might have a subinstance of > SHTextStyler in the 'styler' variable. This is "Shout", originally > from > Squeak. But it might be disabled sometimes, as when the code pane is > showing diffs, or bytecodes, etc. See #okToStyle , where the model > is > asked whether it is appropriate to style each time. > > If you can't solve the problem, point me to the latest version of > CCB, > and briefly describe steps, expected behavior, unwanted behavior (to > be > sure I understand), and I'll take a look. > > Cheers, > Juan Vuletich > > On 30/09/2015 06:45 p.m., Dan Norton wrote: > > Hi Juan, > > > > The editor class seems to remain constant as SmalltalkEditor. To > see what is puzzling: > > > > open a browser on a class with an actual comment > > view the class comment (? button) > > select all of the comment and copy it > > select, then deselect a message category > > paste the comment in the code window as if defining a new > method > > see the difference in presentation > > > > What is making this switch? If I knew where this is done I might > get the behavior I want in > > CCB. > > > > - Dan > > > > On 30 Sep 2015 at 8:19, Juan Vuletich wrote: > > > >> Hi Dan, > >> > >> See the TextEditor hierarchy. See #editorClass, senders and > >> implementors. > >> It is the model who decides what kind of editor to use. > >> > >> An easy way to find out about this, is to realiza that what you > want > >> is > >> the "Smalltalk Options" menu in code panes. Just write > "Smalltalk > >> Options" > >> in some code pane, select it (without the quotes) and do right > click > >> / > >> Smalltalk Options / Method Source with it. That leads you right > to > >> SmalltalkEditor. > >> > >> Cheers, > >> Juan Vuletich > >> > >> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: > >>> Hi Juan, > >>> > >>> > >>> A little help, please. BrowserWindow uses > >>> CodeWindow>>buildMorphicCodePane for the > >>> class comment area. Although this area looks like text, > >> expressions > >>> appearing in class comments can be executed as in a workspace. > >>> > >>> I want the same behavior in Class Comment Browser, but all I > get > >> is text > >>> behavior (no execution). How can this be changed? > >>> > >>> - Dan > >>> > >>> > >>> _______________________________________________ > >>> Cuis mailing list > >>> Cuis at jvuletich.org > >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > >>> > >>> > >> > >> _______________________________________________ > >> Cuis mailing list > >> Cuis at jvuletich.org > >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > > _______________________________________________ > > Cuis mailing list > > Cuis at jvuletich.org > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > From juan at jvuletich.org Wed Oct 7 07:17:40 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 7 Oct 2015 09:17:40 -0300 Subject: [Cuis] Class Comment Browser In-Reply-To: <56147297.21959.20BF33E@dnorton.mindspring.com> References: <560B4A62.7244.292AF3F@dnorton.mindspring.com>, <560C57DC.32345.163B7FF@dnorton.mindspring.com>, <5613BD90.4040204@jvuletich.org> <56147297.21959.20BF33E@dnorton.mindspring.com> Message-ID: <4f40bf8bef60787638764dcb4d9f9a20.squirrel@gator3294.hostgator.com> Hi Dan, If you inspect the InnerTextMorph in your right pane, it has: editor: aTextEditor styler: nil To be able to evaluate code, you need a SmalltalkEditor. This does the trick: CommentGuide >> editorClassFor: textGetter ^SmalltalkEditor If you also want Workspace like syntax highlighting, you need a TextStyler. Add: CommentGuide >> textStylerClassFor: textGetter ^SHTextStylerST80 CommentGuide >> shoutAboutToStyle: aSHTextStyler ^true Keep in mind that most class comments can not be parsed as code! That's why in the regular browser, methods are syntaxHighlighted, but class comments are not. I feel that with the hints I gave you before, you could have found out all this yourself. You will get the most out of Smalltalk if you use the code inspection tools as much as possible, and you are not afraid of exploring, experimenting, and trying to learn how the system works. Cheers, Juan Vuletich On Tue, October 6, 2015 10:17 pm, Dan Norton wrote: > Hi Juan, > > > Delay? What delay? Not to worry :-) I regret that this problem is either > beyond me or I'm blind to it. > > Had to clean up the act a bit because of all the fruitless experiments > but the repo seems to behave OK. It is strongly desired by the (huge?) > user community that the pane containing the comment would behave like a > work space, e.g. allow statements to be executed and names to be > highlighted and used to open a browser. The repo is: > > https://github.com/dhnorton/Cuis-Smalltalk-comments > > > Please let me know what I need to do. > > > - Dan > > > On 6 Oct 2015 at 9:24, Juan Vuletich wrote: > > >> Hi Dan, >> >> >> Apologies for the long delay in answering. >> >> >> I think you mean the text styler, that colorizes Smalltalk code, >> right? Well, an instance of InnerTextMorph might have a subinstance of >> SHTextStyler in the 'styler' variable. This is "Shout", originally >> from Squeak. But it might be disabled sometimes, as when the code pane is >> showing diffs, or bytecodes, etc. See #okToStyle , where the model is >> asked whether it is appropriate to style each time. >> >> If you can't solve the problem, point me to the latest version of >> CCB, >> and briefly describe steps, expected behavior, unwanted behavior (to be >> sure I understand), and I'll take a look. >> >> Cheers, >> Juan Vuletich >> >> >> On 30/09/2015 06:45 p.m., Dan Norton wrote: >> >>> Hi Juan, >>> >>> >>> The editor class seems to remain constant as SmalltalkEditor. To >>> >> see what is puzzling: >>> >>> open a browser on a class with an actual comment view the class >>> comment (? button) select all of the comment and copy it select, then >>> deselect a message category paste the comment in the code window as if >>> defining a new >> method >>> see the difference in presentation >>> >>> What is making this switch? If I knew where this is done I might >>> >> get the behavior I want in >>> CCB. >>> >>> >>> - Dan >>> >>> >>> On 30 Sep 2015 at 8:19, Juan Vuletich wrote: >>> >>> >>>> Hi Dan, >>>> >>>> >>>> See the TextEditor hierarchy. See #editorClass, senders and >>>> implementors. It is the model who decides what kind of editor to use. >>>> >>>> >>>> An easy way to find out about this, is to realiza that what you >>>> >> want >>>> is the "Smalltalk Options" menu in code panes. Just write >> "Smalltalk >> >>>> Options" >>>> in some code pane, select it (without the quotes) and do right >> click >>>> / >>>> Smalltalk Options / Method Source with it. That leads you right >>>> >> to >>>> SmalltalkEditor. >>>> >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> >>>> On Tue, September 29, 2015 11:35 pm, Dan Norton wrote: >>>> >>>>> Hi Juan, >>>>> >>>>> >>>>> >>>>> A little help, please. BrowserWindow uses >>>>> CodeWindow>>buildMorphicCodePane for the >>>>> class comment area. Although this area looks like text, >>>> expressions >>>>> appearing in class comments can be executed as in a workspace. >>>>> >>>>> I want the same behavior in Class Comment Browser, but all I >>>>> >> get >>>> is text >>>>> behavior (no execution). How can this be changed? >>>>> >>>>> - Dan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Cuis mailing list >>>>> Cuis at jvuletich.org >>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Cuis mailing list >>>> Cuis at jvuletich.org >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>>> >>> >>> >>> _______________________________________________ >>> Cuis mailing list >>> Cuis at jvuletich.org >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >> > > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > From Ken.Dickey at Whidbey.com Mon Oct 12 10:05:16 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Mon, 12 Oct 2015 08:05:16 -0700 Subject: [Cuis] veryShortName Message-ID: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Greetings, I have been looking at FileMan and had some confusion with #FmFileEntry>>shortName. 'this.that.txt' asFileEntry name. ==> 'this.that.txt' 'this.that.txt' asFileEntry shortName. ==> 'this' I expected #shortName to answer the same result as baseName. 'this.that.txt' asFileEntry baseName. ==> 'this.that' I find the current behavior confusing. Is there a real need to have #shortName differ from #baseName? If the current #shortName behavior is required, could the name be changed to something nore mnemonic. Perhaps #firstPrefix ? Thanks much, -KenD -- KenD From ume at blueplane.jp Sat Oct 17 00:28:23 2015 From: ume at blueplane.jp (Masashi UMEZAWA) Date: Sat, 17 Oct 2015 14:28:23 +0900 Subject: [Cuis] veryShortName In-Reply-To: <20151012080516.9224a7578af856399be5679f@Whidbey.com> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Message-ID: Hi all, Actually I sometimes uses #shortName for selecting package name part from MCZ files (package.123.mcz). In this case, package name part is not prefix. But #shortName is not so clear, neither. Perhaps #firstName or #nameUpToDot would be better? Best regards, 2015-10-13 0:05 GMT+09:00 KenD : > Greetings, > > I have been looking at FileMan and had some confusion with #FmFileEntry>>shortName. > > 'this.that.txt' asFileEntry name. ==> 'this.that.txt' > 'this.that.txt' asFileEntry shortName. ==> 'this' > > I expected #shortName to answer the same result as baseName. > > 'this.that.txt' asFileEntry baseName. ==> 'this.that' > > I find the current behavior confusing. Is there a real need to have #shortName differ from #baseName? > > If the current #shortName behavior is required, could the name be changed to something nore mnemonic. Perhaps #firstPrefix ? > > Thanks much, > -KenD > > > > > -- > KenD -- [:masashi | ^umezawa] From Ken.Dickey at Whidbey.com Sat Oct 17 09:39:32 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sat, 17 Oct 2015 07:39:32 -0700 Subject: [Cuis] veryShortName In-Reply-To: References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> Message-ID: <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> On Sat, 17 Oct 2015 14:28:23 +0900 Masashi UMEZAWA wrote: > Perhaps #firstName or #nameUpToDot would be better? Yes. Either works for me. Thanks, KenD From dnorton at mindspring.com Tue Oct 20 15:43:02 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 20 Oct 2015 16:43:02 -0400 Subject: [Cuis] PluggableListMorph Message-ID: <5626A756.25587.11E39F9@dnorton.mindspring.com> Greetings, PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be daunting because of the use of the dependency mechanism. AFAICT the tools do not display dependencies and even if they did, it's not clear why some of them exist. What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar that can be in the Terse Guide. It should show an example of selection in one list causing the population of another list and selection in that list causing the population of some other morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a method sends #changed: with a parameter referring to another method - why? The design needs to be explained. - Dan From Ken.Dickey at Whidbey.com Thu Oct 22 17:39:04 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Thu, 22 Oct 2015 15:39:04 -0700 Subject: [Cuis] PluggableListMorph In-Reply-To: <5626A756.25587.11E39F9@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com> Message-ID: <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> On Tue, 20 Oct 2015 16:43:02 -0400 "Dan Norton" wrote: > PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be > daunting because of the use of the dependency mechanism. AFAICT the tools do not display > dependencies and even if they did, it's not clear why some of them exist. > > What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar > that can be in the Terse Guide. It should show an example of selection in one list causing the > population of another list and selection in that list causing the population of some other > morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a > method sends #changed: with a parameter referring to another method - why? The design > needs to be explained. Dan, +1 A tool to detect/show such "out of band" control/change linkages/dependencies would be most welcomed, as would a Principles of Operation. Taking a quick look at my own code ("guilty as charged, sir") >> grep "changed:" */*.st Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! ! Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #actualContents! ! Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. I see two cases where one wants to be notified of changes without adding specific code to individual morph instances. In each case one wants to propagate updates to dependent views. [1] Change in internal Morph state should update viewers onto that state. [2] The special case of selection change in a list (PlugableListMorph) should update dependent viewers. So the simple explanation for "WHY change notification" is to update (perhaps multiple) viewers without doing special notification code in the Morphs being viewed. The target Morph should not have to know how many, if any, views onto its state exist. HOW is the registration process: Class ActiveModel and its subclass: SystemChangeNotifier I am a rare user of the change notification mechanism and would also benefit from good documentation and better tool(s) in this area. Cheers, KenD From dnorton at mindspring.com Fri Oct 23 10:56:26 2015 From: dnorton at mindspring.com (Dan Norton) Date: Fri, 23 Oct 2015 11:56:26 -0400 Subject: [Cuis] PluggableListMorph In-Reply-To: <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> Message-ID: <562A58AA.15972.4E08E7@dnorton.mindspring.com> On 22 Oct 2015 at 15:39, KenD wrote: > On Tue, 20 Oct 2015 16:43:02 -0400 > "Dan Norton" wrote: > > > PluggableListMorph has valuable behavior but applying it in morphs > with multiple lists can be > > daunting because of the use of the dependency mechanism. AFAICT > the tools do not display > > dependencies and even if they did, it's not clear why some of them > exist. > > > > What is needed is a "PluggableListMorph Principles of Operation" > doc, or something similar > > that can be in the Terse Guide. It should show an example of > selection in one list causing the > > population of another list and selection in that list causing the > population of some other > > morph. Isn't that like FileList? Yes, but we need the whys and > wherefors. For example, a > > method sends #changed: with a parameter referring to another > method - why? The design > > needs to be explained. > > Dan, > > +1 > > A tool to detect/show such "out of band" control/change > linkages/dependencies would be most welcomed, as would a Principles > of Operation. > > Taking a quick look at my own code ("guilty as charged, sir") > > >> grep "changed:" */*.st > Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph > Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! > ! > Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. > Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > #actualContents! ! > Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. > Hi Ken, In #actualContents: there is "self changed: #actualContents" which seems reasonable. However, in #refetch there is "self changed: #refetch" which is perplexing because it looks like infinite recursion, but it must be OK because similar examples appear in Browser. - Dan From juan at jvuletich.org Fri Oct 23 11:31:51 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 13:31:51 -0300 Subject: [Cuis] PluggableListMorph In-Reply-To: <5626A756.25587.11E39F9@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com> Message-ID: <562A60F7.1070702@jvuletich.org> Hi Dan, On 20/10/2015 05:43 p.m., Dan Norton wrote: > Greetings, > > PluggableListMorph has valuable behavior but applying it in morphs with multiple lists can be > daunting because of the use of the dependency mechanism. AFAICT the tools do not display > dependencies and even if they did, it's not clear why some of them exist. Yes. Most tools are still using the changed:/update: dependency mechanism that comes from MVC in Smalltalk-80. Later, Squeak and Cuis also included the #when:send:to: event system. It should replace changed:/update: in all client code because it helps produce code that is easier to understand. This is something we should do at some moment. > What is needed is a "PluggableListMorph Principles of Operation" doc, or something similar > that can be in the Terse Guide. It should show an example of selection in one list causing the > population of another list and selection in that list causing the population of some other > morph. Isn't that like FileList? Yes, but we need the whys and wherefors. For example, a > method sends #changed: with a parameter referring to another method - why? The design > needs to be explained. > > - Dan Most likely all the classic references apply (In the blue book? Or most likely in Inside Smalltalk vol II). I'm sure there are others. Including excepts and/or references to them in TerseGuide would indeed be great. Please also keep in mind that this is not only for lists. It is essentially the same mechanism used for text panes, buttons, lists, tree lists, etc. Thanks, Juan Vuletich From juan at jvuletich.org Fri Oct 23 11:59:43 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 13:59:43 -0300 Subject: [Cuis] PluggableListMorph In-Reply-To: <562A58AA.15972.4E08E7@dnorton.mindspring.com> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <20151022153904.40888365fc2ac7ff6cfef54d@Whidbey.com> <562A58AA.15972.4E08E7@dnorton.mindspring.com> Message-ID: <562A677F.50500@jvuletich.org> On 23/10/2015 12:56 p.m., Dan Norton wrote: > On 22 Oct 2015 at 15:39, KenD wrote: > >> On Tue, 20 Oct 2015 16:43:02 -0400 >> "Dan Norton" wrote: >> >>> PluggableListMorph has valuable behavior but applying it in morphs >> with multiple lists can be >>> daunting because of the use of the dependency mechanism. AFAICT >> the tools do not display >>> dependencies and even if they did, it's not clear why some of them >> exist. >>> What is needed is a "PluggableListMorph Principles of Operation" >> doc, or something similar >>> that can be in the Terse Guide. It should show an example of >> selection in one list causing the >>> population of another list and selection in that list causing the >> population of some other >>> morph. Isn't that like FileList? Yes, but we need the whys and >> wherefors. For example, a >>> method sends #changed: with a parameter referring to another >> method - why? The design >>> needs to be explained. >> Dan, >> >> +1 >> >> A tool to detect/show such "out of band" control/change >> linkages/dependencies would be most welcomed, as would a Principles >> of Operation. >> >> Taking a quick look at my own code ("guilty as charged, sir") >> >>>> grep "changed:" */*.st >> Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #actualContents! >> ! >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: >> #actualContents! ! >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: #refetched. >> > Hi Ken, > > In #actualContents: there is "self changed: #actualContents" which seems reasonable. > > However, in #refetch there is "self changed: #refetch" which is perplexing because it looks > like infinite recursion, but it must be OK because similar examples appear in Browser. > > - Dan Just look at senders of #refetched . (not refetch!) It is quite simple, actually. To see a bit more on how lists are used, see references to PluggableListMorph. The second is #buildMorphicMessageCatList. See how it parametrizes the instance it builds. These methods that create various lists are quite similar, and all they do is to bind each list with a different aspect of the model. In this case, with #messageCategoryList. See implementors and senders. It is clear that the implementors are methods in models that answer (guess what!!!!) a list of message categories. When you look at senders senders, you can see that some are in the model, doing things like 'self changed: #messageCategoryList'. It is easy to see that this means that the list of message categories have changed, and anybody depending on that should update itself. Now we have a detail that is not that obvious, and most likely the clue you need to understand this all. See implementors of #update: in PluggableListMorph and the other PluggableMorph classes. #update: compares the argument with the listGetter (or the appropriate ivar for each morph). So, when the model does 'self changed: #messageCategoryList', all dependent morphs get message 'eachMorph update: #messageCategoryList'. And only those morphs that were configured to watch on this symbol with react. As I said before, this is the changed/update mechanism in MVC in Smalltlk-80. Using #when:send:to: insted would lead to better code. But documenting the current state of the system is needed and important, Cheers, Juan Vuletich From juan at jvuletich.org Fri Oct 23 12:22:19 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 14:22:19 -0300 Subject: [Cuis] veryShortName In-Reply-To: <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> Message-ID: <562A6CCB.6000603@jvuletich.org> On 17/10/2015 11:39 a.m., KenD wrote: > On Sat, 17 Oct 2015 14:28:23 +0900 > Masashi UMEZAWA wrote: > >> Perhaps #firstName or #nameUpToDot would be better? > Yes. Either works for me. > > Thanks, > KenD > Besides #shortName, we also have #splitNameVersionExtensionFor:, #baseNameFor:, #baseName, etc. Reducing their number would be good. As it would be to separate those that give a "standard service" from those that just solve a more specific need of some client code. Cheers, Juan Vuletich From juan at jvuletich.org Fri Oct 23 13:49:15 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Fri, 23 Oct 2015 15:49:15 -0300 Subject: [Cuis] New Commit: FileMan adoption and tweaks Message-ID: <562A812B.7090101@jvuletich.org> Hi Folks, I've just updated github. I did many changes, to adopt FileMan almost everywhere in Cuis and core packages.I did a few changes to FileMan and the API. The one you might notice is that I've made FmFileEntry and FmDirectoryEntry siblings, under a new FmEntry. Now, each class is more specific: FmFileEntry doesn't handle Directory responsibilities (like creating files in it) and FmDirectoryEntry doesn't support File responsibility (like creating a FileStream on itself). I think it is much cleaner this way. The change you might need to care about is that 'dirName' asDirectoryEntry / 'subdir' answers an FmDirectoryEntry and the new #//: 'dirName' asDirectoryEntry // 'filename' answers an FmFileEntry. Please adapt your packages to the new FileMan API, as the old FileDirectory hierarchy will be deprecated soon, and later removed from Cuis. Oh, this commit also includes new versions of TerseGuide and ClassCommentBrowser by Dan Norton. (Thanks Dan!) Cheers, Juan Vuletich From pbpublist at gmail.com Fri Oct 23 16:10:42 2015 From: pbpublist at gmail.com (Phil (list)) Date: Fri, 23 Oct 2015 17:10:42 -0400 Subject: [Cuis] Effect of Cursor Movement In-Reply-To: <55F307E2.4040706@jvuletich.org> References: <55F2FF07.16923.7339F5@dnorton.mindspring.com> <55F307E2.4040706@jvuletich.org> Message-ID: <1445634642.3451.6.camel@gmail.com> On Fri, 2015-09-11 at 13:57 -0300, Juan Vuletich wrote: > Hi Dan, > > (below) > On 9/11/2015 1:19 PM, Dan Norton wrote: > > Hello, > > > > To see this, Bring up BouncingAtomsMorph, enlarge the window, set a > > high atoms count so > > that you can easily sense atom movement. > > > > Notice how movement speeds up when the cursor is moved and slows > > when it stops? Turn > > on FPS. On my machine, frame rate is about 22 with no cursor > > movement and increases to > > around 36 when the cursor is moving. The cursor does not have to be > > in the window. It can > > be anywhere. > > > > Why should that be? It may not be a problem, but it is a curiosity. > > Any explanation? > > > > BTW this is Win7, cogwin-15.33.3427, Cuis 2478. > > > > ? - Dan > > Haven't even taken a look, so if I did maybe I would find something > else... but for sure Cuis is triggering MouseMoveEvents, and looking > for > possible interested parties. That, on each Morphic cycle. So, each > Morphic cycle might take a bit longer, and FPS can go a bit down. > > In any case, if you are curious, you can take a closer look. Often, > questions like this lead to possible optimizations! > The issue he's describing sounds like the opposite of that. ?Any chance this is related to the issue we discussed on vm-dev back in 2012? (The thread was titled "Cog VM idling performance") ?Your fix back then mostly addressed the issue (I've noticed some minor idling slowdowns since then, but nothing as extreme as when I originally reported the issue) Funny thing is I think I'm now dealing with the other side of this problem in Seaside: I have a situation where an idling VM is consuming too much CPU... (nothing specifically related to Cuis other than the warning to 'be careful of what you wish for' :-) > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org From dnorton at mindspring.com Fri Oct 23 18:04:27 2015 From: dnorton at mindspring.com (Dan Norton) Date: Fri, 23 Oct 2015 19:04:27 -0400 Subject: [Cuis] PluggableListMorph In-Reply-To: <562A677F.50500@jvuletich.org> References: <5626A756.25587.11E39F9@dnorton.mindspring.com>, <562A58AA.15972.4E08E7@dnorton.mindspring.com>, <562A677F.50500@jvuletich.org> Message-ID: <562ABCFB.20558.1D5E5B6@dnorton.mindspring.com> On 23 Oct 2015 at 13:59, Juan Vuletich wrote: > On 23/10/2015 12:56 p.m., Dan Norton wrote: > > On 22 Oct 2015 at 15:39, KenD wrote: > > > >> On Tue, 20 Oct 2015 16:43:02 -0400 > >> "Dan Norton" wrote: > >> > >>> PluggableListMorph has valuable behavior but applying it in > morphs > >> with multiple lists can be > >>> daunting because of the use of the dependency mechanism. > AFAICT > >> the tools do not display > >>> dependencies and even if they did, it's not clear why some of > them > >> exist. > >>> What is needed is a "PluggableListMorph Principles of > Operation" > >> doc, or something similar > >>> that can be in the Terse Guide. It should show an example of > >> selection in one list causing the > >>> population of another list and selection in that list causing > the > >> population of some other > >>> morph. Isn't that like FileList? Yes, but we need the whys and > >> wherefors. For example, a > >>> method sends #changed: with a parameter referring to another > >> method - why? The design > >>> needs to be explained. > >> Dan, > >> > >> +1 > >> > >> A tool to detect/show such "out of band" control/change > >> linkages/dependencies would be most welcomed, as would a > Principles > >> of Operation. > >> > >> Taking a quick look at my own code ("guilty as charged, sir") > >> > >>>> grep "changed:" */*.st > >> Cuis-Smalltalk-BabySteps/PropertyEditor.pck.st:changed: myMorph > >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: > #actualContents! > >> ! > >> Cuis-Smalltalk-Ropes/Ropes.pck.st: self changed: #refetched. > >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > >> #actualContents! ! > >> Cuis-Smalltalk-Unicode/UniCodes.pck.st: self changed: > #refetched. > >> > > Hi Ken, > > > > In #actualContents: there is "self changed: #actualContents" which > seems reasonable. > > > > However, in #refetch there is "self changed: #refetch" which is > perplexing because it looks > > like infinite recursion, but it must be OK because similar > examples appear in Browser. > > > > - Dan > > Just look at senders of #refetched . (not refetch!) It is quite > simple, > actually. > > To see a bit more on how lists are used, see references to > PluggableListMorph. The second is #buildMorphicMessageCatList. See > how > it parametrizes the instance it builds. These methods that create > various lists are quite similar, and all they do is to bind each > list > with a different aspect of the model. In this case, with > #messageCategoryList. See implementors and senders. It is clear that > the > implementors are methods in models that answer (guess what!!!!) a > list > of message categories. When you look at senders senders, you can see > that some are in the model, doing things like 'self changed: > #messageCategoryList'. It is easy to see that this means that the > list > of message categories have changed, and anybody depending on that > should > update itself. > > Now we have a detail that is not that obvious, and most likely the > clue > you need to understand this all. See implementors of #update: in > PluggableListMorph and the other PluggableMorph classes. #update: > compares the argument with the listGetter (or the appropriate ivar > for > each morph). So, when the model does 'self changed: > #messageCategoryList', all dependent morphs get message 'eachMorph > update: #messageCategoryList'. And only those morphs that were > configured to watch on this symbol with react. > > As I said before, this is the changed/update mechanism in MVC in > Smalltlk-80. Ah. That's the key - I haven't looked at MVC in years. The model need not know about any view. It is the dependee, signalling happenings that the dependents might like to know. What dependents do starts with their #update: message which may take action after looking at the parameter (or not). The views are dependents of the model. It's misleading when parameters of #changed: look just like message selectors in the model. It gives the impression that those messages are to be sent or invoked, when all that's necessary is that the parameter be understood by the model. That is why it looks like infinite recursion when a method says: refetched ... self changed: #refetched. Far better if the parameter was "foobar or #putDataInTheTextMorphs or the like. > Using #when:send:to: insted would lead to better code. I will definitely start doing that. > But > documenting the current state of the system is needed and > important, With this insight, I may be able to do that now. - Dan From Ken.Dickey at Whidbey.com Fri Oct 23 22:50:16 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Fri, 23 Oct 2015 20:50:16 -0700 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <562A812B.7090101@jvuletich.org> References: <562A812B.7090101@jvuletich.org> Message-ID: <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> On Fri, 23 Oct 2015 15:49:15 -0300 Juan Vuletich wrote: > Hi Folks, > > I've just updated github. I did many changes, to adopt FileMan almost > everywhere in Cuis and core packages. You might want to update: SystemDictionary>>openSourcesAndChanges BTW, I was using String>>upToLastPathSeparator Any chance of getting it back? Cheers, -KenD -------------- next part -------------- A non-text attachment was scrubbed... Name: invoke.out Type: application/octet-stream Size: 3041 bytes Desc: not available URL: From ume at blueplane.jp Sun Oct 25 09:15:18 2015 From: ume at blueplane.jp (Masashi UMEZAWA) Date: Sun, 25 Oct 2015 23:15:18 +0900 Subject: [Cuis] veryShortName In-Reply-To: <562A6CCB.6000603@jvuletich.org> References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> <562A6CCB.6000603@jvuletich.org> Message-ID: Hi all, Indeed, we should avoid adding ad-hoc methods. Currently I'm thinking to introduce a more generic API (splitName:by:) to FmFileIOAccessor. So we can implement FmFileEntry methods more consistently like: FmFileEntry >> firstName ^ (self fileAccessor splitName: self name by: self extensionDelimiter) first FmFileEntry >> extension ^ (self fileAccessor splitName: self name by: self extensionDelimiter) last FmFileEntry >> baseName | names | names := self fileAccessor splitName: self name by: self extensionDelimiter. names size = 1 ifTrue: [^names first]. ^self extensionDelimiter join: names allButLast Best regards, 2015-10-24 2:22 GMT+09:00 Juan Vuletich : > On 17/10/2015 11:39 a.m., KenD wrote: >> >> On Sat, 17 Oct 2015 14:28:23 +0900 >> Masashi UMEZAWA wrote: >> >>> Perhaps #firstName or #nameUpToDot would be better? >> >> Yes. Either works for me. >> >> Thanks, >> KenD >> > > Besides #shortName, we also have #splitNameVersionExtensionFor:, > #baseNameFor:, #baseName, etc. Reducing their number would be good. As it > would be to separate those that give a "standard service" from those that > just solve a more specific need of some client code. > > Cheers, > Juan Vuletich -- [:masashi | ^umezawa] From pavel.krivanek at gmail.com Sun Oct 25 10:36:09 2015 From: pavel.krivanek at gmail.com (Pavel Krivanek) Date: Sun, 25 Oct 2015 16:36:09 +0100 Subject: [Cuis] smallest Cuis image with Morphic Message-ID: Hi, is there the old minimal Cuis image (about 2MB with Morphic) still somewhere to download? Cheers, -- Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Sun Oct 25 11:19:38 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sun, 25 Oct 2015 09:19:38 -0700 Subject: [Cuis] veryShortName In-Reply-To: References: <20151012080516.9224a7578af856399be5679f@Whidbey.com> <20151017073932.d8613fa1e6ab15787ec29e9c@Whidbey.com> <562A6CCB.6000603@jvuletich.org> Message-ID: <20151025091938.1f28b5c26bb7cdbb5d462c6c@Whidbey.com> On Sun, 25 Oct 2015 23:15:18 +0900 Masashi UMEZAWA wrote: > Currently I'm thinking to introduce a more generic API (splitName:by:) > to FmFileIOAccessor. That would be great! Juan, would you let me know when this is integrated? I/we need to update/replace StandardFileMenu. Thanks much, -KenD From 0800nacho at gmail.com Sun Oct 25 13:03:27 2015 From: 0800nacho at gmail.com (nacho) Date: Sun, 25 Oct 2015 11:03:27 -0700 (PDT) Subject: [Cuis] Changing Wallpaper Message-ID: <1445796207751-4857882.post@n4.nabble.com> Hi Folks, I know how to take out the default Cuis wallpaper and change it with a solid color. However, I'm not able to use another image. What are the steps needed to get this done? Thanks in advance Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Sun Oct 25 17:11:26 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Sun, 25 Oct 2015 19:11:26 -0300 Subject: [Cuis] smallest Cuis image with Morphic In-Reply-To: References: Message-ID: <562D538E.5090406@jvuletich.org> On 25/10/2015 12:36 p.m., Pavel Krivanek wrote: > Hi, > > is there the old minimal Cuis image (about 2MB with Morphic) still > somewhere to download? > > Cheers, > -- Pavel > > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org Hi Pavel, Yes. It is still at www.jvuletich.org/Cuis/Cuis3.1r3.zip . You'll need a sources file. You can get it from www.jvuletich.org/Cuis/Cuis3.1-0850.zip . Please note that it is possible to build such a small image from a current Cuis, if desired. Cheers, Juan Vuletich Ps. I'm sure you're on something interesting with this. Could you please tell a bit? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Sun Oct 25 17:56:31 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Sun, 25 Oct 2015 15:56:31 -0700 Subject: [Cuis] smallest Cuis image with Morphic In-Reply-To: <562D538E.5090406@jvuletich.org> References: <562D538E.5090406@jvuletich.org> Message-ID: <20151025155631.e9f696d0b85c0bcff578f5ed@Whidbey.com> On Sun, 25 Oct 2015 19:11:26 -0300 Juan Vuletich wrote: .. > Please note that it is possible to build such a small image from a > current Cuis, if desired. BTW, I tried Smalltalk reduceCuis. in 2555 but it seems to go into a loop at AnObsoleteUnixFileDirectory class(FileDirectory class)>>pathDelimiter Smalltalk reduceCuis. is successful under 2528 and produces 4.8 Mb image FYI, -KenD From dnorton at mindspring.com Mon Oct 26 15:58:12 2015 From: dnorton at mindspring.com (Dan Norton) Date: Mon, 26 Oct 2015 16:58:12 -0400 Subject: [Cuis] PluggableListMorph Message-ID: <562E93E4.6994.128E352@dnorton.mindspring.com> Hello All, Please review the following for accuracy. It's not complete. It's a start on a "Principles of Operation" for applying PluggableListMorph for fun and profit. Maybe it should be called "PluggableListMorph for Dummies". I'm especially interested in whether you agree with the "coincidental" statement. PluggableListMorph is designed to work as part of one or more views on a model in the MVC paradigm (Note 1). The model is not directly aware of the existence of any view; instead, it signals changes in itself by broadcasting symbols with the #changed: method. In this way, any view which is related to the model can detect the changes by examining the symbol in its #update: method. Thus while the model is not explicitly aware of a view, there is an implicit relationship in that a view must know the significance of the symbols broadcast by the model in order to respond appropriately. Views are dependents of a model and therefore the model is a sponsor of views. Use of the #changed: and #update: methods is the essence of the Smalltalk dependency mechanism (Inside II). The model sends #changed: and as a result, all dependents (e.g. views) on it receive #update:. In the #update: method, the view examines the symbol and decides what, if anything, to do. While the symbol is, in practice, often identical to the name of a method, this is coincidental and unfortunately a source of confusion and misdirection. Note 1. The MVC paradigm is mentioned here for historical context. PluggableListMorph can also be employed in other design schemes. Inside II. LaLonde and Pugh, "Inside Smalltalk, Volume II" Thanks, - Dan From Ken.Dickey at Whidbey.com Mon Oct 26 17:39:42 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Mon, 26 Oct 2015 15:39:42 -0700 Subject: [Cuis] PluggableListMorph In-Reply-To: <562E93E4.6994.128E352@dnorton.mindspring.com> References: <562E93E4.6994.128E352@dnorton.mindspring.com> Message-ID: <20151026153942.aebae2c125a712e22f4b9fa6@Whidbey.com> Hi Dan, Good explanation. I like good explanations. 8) You might be interested in the code examples in: http://stackoverflow.com/questions/17082576/implementing-the-observer-pattern-in-smalltalk-visualworks I would note that the observer pattern discussion might be better served by the more modern #when:send:to: idiom. [E.g. look at when:send:to: senders; Check the TaskBar for simple usage]. In particular, an observer can register for event updates and get a specific message. IMHO we should rewrite PluggableListMorph to use when:send:to: $0.02 -KenD From 0800nacho at gmail.com Tue Oct 27 10:02:53 2015 From: 0800nacho at gmail.com (nacho) Date: Tue, 27 Oct 2015 08:02:53 -0700 (PDT) Subject: [Cuis] Changing Wallpaper In-Reply-To: <1445796207751-4857882.post@n4.nabble.com> References: <1445796207751-4857882.post@n4.nabble.com> Message-ID: <1445958173832-4858215.post@n4.nabble.com> It seems that I have to convert the image as an array, isn't it? ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882p4858215.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From dnorton at mindspring.com Tue Oct 27 10:23:49 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 27 Oct 2015 11:23:49 -0400 Subject: [Cuis] Could Not Find Feature Requirement Message-ID: <562F9705.519.430ADA@dnorton.mindspring.com> Cuis4.2-2528 successfully loads a package with a feature requirement. With Cuis4.2-2555, loading the same package gets: Error:Could not find package supplying feature: FeatureRequirement(Records 1.15 to *.*) - Dan From hannes.hirzel at gmail.com Tue Oct 27 11:27:58 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue, 27 Oct 2015 17:27:58 +0100 Subject: [Cuis] Changing Wallpaper In-Reply-To: <1445958173832-4858215.post@n4.nabble.com> References: <1445796207751-4857882.post@n4.nabble.com> <1445958173832-4858215.post@n4.nabble.com> Message-ID: Have a look at PasteUpMorph >> backgroundImageData: aByteArray Then do something like | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: (FileStream readOnlyFileNamed: filename) binary contentsOfEntireFile. HTH --Hannes On 10/27/15, nacho <0800nacho at gmail.com> wrote: > It seems that I have to convert the image as an array, isn't it? > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/Changing-Wallpaper-tp4857882p4858215.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From dnorton at mindspring.com Tue Oct 27 13:04:10 2015 From: dnorton at mindspring.com (Dan Norton) Date: Tue, 27 Oct 2015 14:04:10 -0400 Subject: [Cuis] Could Not Find Feature Requirement Message-ID: <562FBC9A.2992.D5D887@dnorton.mindspring.com> If a copy of the required feature is placed in the directory of the image, the package loads successfully, - Dan From 0800nacho at gmail.com Tue Oct 27 15:29:37 2015 From: 0800nacho at gmail.com (nacho) Date: Tue, 27 Oct 2015 13:29:37 -0700 (PDT) Subject: [Cuis] Changing Wallpaper In-Reply-To: References: <1445796207751-4857882.post@n4.nabble.com> <1445958173832-4858215.post@n4.nabble.com> Message-ID: <1445977777218-4858263.post@n4.nabble.com> Thank you !!! That worked perfectly!! ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Changing-Wallpaper-tp4857882p4858263.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Wed Oct 28 09:14:57 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:14:57 -0300 Subject: [Cuis] Effect of Cursor Movement In-Reply-To: <1445634642.3451.6.camel@gmail.com> References: <55F2FF07.16923.7339F5@dnorton.mindspring.com> <55F307E2.4040706@jvuletich.org> <1445634642.3451.6.camel@gmail.com> Message-ID: <5630D861.2090509@jvuletich.org> Hi Folks, (inline) On 10/23/2015 6:10 PM, Phil (list) wrote: > On Fri, 2015-09-11 at 13:57 -0300, Juan Vuletich wrote: >> Hi Dan, >> >> (below) >> On 9/11/2015 1:19 PM, Dan Norton wrote: >>> Hello, >>> >>> To see this, Bring up BouncingAtomsMorph, enlarge the window, set a >>> high atoms count so >>> that you can easily sense atom movement. >>> >>> Notice how movement speeds up when the cursor is moved and slows >>> when it stops? Turn >>> on FPS. On my machine, frame rate is about 22 with no cursor >>> movement and increases to >>> around 36 when the cursor is moving. The cursor does not have to be >>> in the window. It can >>> be anywhere. >>> >>> Why should that be? It may not be a problem, but it is a curiosity. >>> Any explanation? >>> >>> BTW this is Win7, cogwin-15.33.3427, Cuis 2478. >>> >>> - Dan >> Haven't even taken a look, so if I did maybe I would find something >> else... but for sure Cuis is triggering MouseMoveEvents, and looking >> for >> possible interested parties. That, on each Morphic cycle. So, each >> Morphic cycle might take a bit longer, and FPS can go a bit down. >> >> In any case, if you are curious, you can take a closer look. Often, >> questions like this lead to possible optimizations! >> > The issue he's describing sounds like the opposite of that. Any chance > this is related to the issue we discussed on vm-dev back in 2012? (The > thread was titled "Cog VM idling performance") Your fix back then > mostly addressed the issue (I've noticed some minor idling slowdowns > since then, but nothing as extreme as when I originally reported the > issue) Thanks for the heads-up. You are right. The issue is related to that code. I fixed it, and now BouncingAtomsMorph fps is quite better and independent of user activity! > Funny thing is I think I'm now dealing with the other side of this > problem in Seaside: I have a situation where an idling VM is consuming > too much CPU... (nothing specifically related to Cuis other than the > warning to 'be careful of what you wish for' :-) Check for #serverMode. This sould fix that problem. You can tweak it to devote very little cpu to Morphic (with sluggish Morphic when you need it). Squeak also has it. Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:16:14 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:16:14 -0300 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> Message-ID: <5630D8AE.8030803@jvuletich.org> Hi Ken, On 10/24/2015 12:50 AM, KenD wrote: > On Fri, 23 Oct 2015 15:49:15 -0300 > Juan Vuletich wrote: > >> Hi Folks, >> >> I've just updated github. I did many changes, to adopt FileMan almost >> everywhere in Cuis and core packages. > You might want to update: > SystemDictionary>>openSourcesAndChanges Of course. Done. I've just commited an image that no longer includes FileDirectory!!! > BTW, I was using String>>upToLastPathSeparator > > Any chance of getting it back? Sure. Added it back. > Cheers, > -KenD Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:19:05 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:19:05 -0300 Subject: [Cuis] Could Not Find Feature Requirement In-Reply-To: <562F9705.519.430ADA@dnorton.mindspring.com> References: <562F9705.519.430ADA@dnorton.mindspring.com> Message-ID: <5630D959.5040903@jvuletich.org> On 10/27/2015 12:23 PM, Dan Norton wrote: > Cuis4.2-2528 successfully loads a package with a feature requirement. > > With Cuis4.2-2555, loading the same package gets: > > Error:Could not find package supplying feature: FeatureRequirement(Records 1.15 to *.*) > > - Dan > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > Please try with the latest image. If you still have problems, give details about the directory structure that makes it fail. Cheers, Juan Vuletich From juan at jvuletich.org Wed Oct 28 09:55:12 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Wed, 28 Oct 2015 11:55:12 -0300 Subject: [Cuis] New Commit: FileDirectory finally gone! Message-ID: <5630E1D0.7070907@jvuletich.org> Hi Folks, I finished the migration to FileMan. I removed the FileDirectory and DirectoryEntry hierarchies. I also removed a few rather ambiguous creation methods in StandardFileStream. Please update your packages and code accordingly. FileMan is so much nicer to use! Especially, prefer #writeStream: and #readStream: methods, that do the close for you (even in the presence of errors, etc). There might be details that still need tweaking. Let's go into a stabilization phase with this. When we are all happy, we can call it Cuis 5.0. Cuis keeps showing us that constant cleaning and simplification enables this kind of deep changes and evolution. This is so much better than simply adding yet-another-API-for-doing-the-same-thing, as other Smalltalk environments are forced to do! Cheers, Juan Vuletich From garduino at gmail.com Wed Oct 28 10:25:45 2015 From: garduino at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Arduino?=) Date: Wed, 28 Oct 2015 12:25:45 -0300 Subject: [Cuis] New Commit: FileDirectory finally gone! In-Reply-To: <5630E1D0.7070907@jvuletich.org> References: <5630E1D0.7070907@jvuletich.org> Message-ID: +1 ! Saludos / Regards, Germ?n Arduino @garduino 2015-10-28 11:55 GMT-03:00 Juan Vuletich : > Hi Folks, > > I finished the migration to FileMan. I removed the FileDirectory and > DirectoryEntry hierarchies. I also removed a few rather ambiguous creation > methods in StandardFileStream. Please update your packages and code > accordingly. FileMan is so much nicer to use! Especially, prefer > #writeStream: and #readStream: methods, that do the close for you (even in > the presence of errors, etc). > > There might be details that still need tweaking. Let's go into a > stabilization phase with this. When we are all happy, we can call it Cuis > 5.0. > > Cuis keeps showing us that constant cleaning and simplification enables > this kind of deep changes and evolution. This is so much better than simply > adding yet-another-API-for-doing-the-same-thing, as other Smalltalk > environments are forced to do! > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ken.Dickey at Whidbey.com Wed Oct 28 11:05:34 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Wed, 28 Oct 2015 09:05:34 -0700 Subject: [Cuis] New Commit: FileDirectory finally gone! In-Reply-To: <5630E1D0.7070907@jvuletich.org> References: <5630E1D0.7070907@jvuletich.org> Message-ID: <20151028090534.bdade822ea0f0e0ca2739444@Whidbey.com> On Wed, 28 Oct 2015 11:55:12 -0300 Juan Vuletich wrote: > There might be details that still need tweaking. Let's go into a > stabilization phase with this. When we are all happy, we can call it > Cuis 5.0. WooHoo! 8^) > Cuis keeps showing us that constant cleaning and simplification enables > this kind of deep changes and evolution. This is so much better than > simply adding yet-another-API-for-doing-the-same-thing, as other > Smalltalk environments are forced to do! Just tries Solitaire and noted it is significant faster. Current Class count is 504. Juan, you have much to be proud about. Thanks once again for Cuis!!! -- -KenD ================ count := 0. Metaclass allInstancesDo: [ :ignore | count := count + 1 ]. count. "==> 504" ================ From dnorton at mindspring.com Wed Oct 28 13:29:13 2015 From: dnorton at mindspring.com (Dan Norton) Date: Wed, 28 Oct 2015 14:29:13 -0400 Subject: [Cuis] Could Not Find Feature Requirement In-Reply-To: <5630D959.5040903@jvuletich.org> References: <562F9705.519.430ADA@dnorton.mindspring.com>, <5630D959.5040903@jvuletich.org> Message-ID: <563113F9.4492.E99BF5@dnorton.mindspring.com> On 28 Oct 2015 at 11:19, Juan Vuletich wrote: > On 10/27/2015 12:23 PM, Dan Norton wrote: > > Cuis4.2-2528 successfully loads a package with a feature > requirement. > > > > With Cuis4.2-2555, loading the same package gets: > > > > Error:Could not find package supplying feature: > FeatureRequirement(Records 1.15 to *.*) > > > > - Dan > > > > _______________________________________________ > > Cuis mailing list > > Cuis at jvuletich.org > > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > Please try with the latest image. If you still have problems, give > details about the directory structure that makes it fail. > Hi Juan, You fixed it in Cuis4.2-2563! Thanks much! - Dan From 0800nacho at gmail.com Wed Oct 28 14:18:55 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 12:18:55 -0700 (PDT) Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <5630D8AE.8030803@jvuletich.org> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> Message-ID: <1446059935002-4858359.post@n4.nabble.com> So now, for importing a new wallpaper, instead of doing: | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: (FileStream readOnlyFileNamed: filename) binary contentsOfEntireFile. What Class and method should I use? Because FileStream>>readOnlyFileNamed: is no longer there. thanks in advance! nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From hannes.hirzel at gmail.com Wed Oct 28 16:38:18 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Wed, 28 Oct 2015 22:38:18 +0100 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: <1446059935002-4858359.post@n4.nabble.com> References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: | filename | filename _ 'Pluto.png'. self runningWorld backgroundImageData: filename asFileEntry binaryContents. On 10/28/15, nacho <0800nacho at gmail.com> wrote: > So now, for importing a new wallpaper, instead of doing: > > | filename | > filename _ 'Pluto.png'. > self runningWorld backgroundImageData: > (FileStream readOnlyFileNamed: filename) binary > contentsOfEntireFile. > > What Class and method should I use? Because FileStream>>readOnlyFileNamed: > is no longer there. > thanks in advance! > nacho > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: > http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From hannes.hirzel at gmail.com Wed Oct 28 16:50:32 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Wed, 28 Oct 2015 22:50:32 +0100 Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: N.B. Have a look at the class comment of FmFileEntry and the seven example methods on the class side. And String>>asFileEntry There is a need for an example for #binaryContents and #binaryContents: On 10/28/15, H. Hirzel wrote: > | filename | > filename _ 'Pluto.png'. > self runningWorld backgroundImageData: filename asFileEntry > binaryContents. > > > On 10/28/15, nacho <0800nacho at gmail.com> wrote: >> So now, for importing a new wallpaper, instead of doing: >> >> | filename | >> filename _ 'Pluto.png'. >> self runningWorld backgroundImageData: >> (FileStream readOnlyFileNamed: filename) binary >> contentsOfEntireFile. >> >> What Class and method should I use? Because >> FileStream>>readOnlyFileNamed: >> is no longer there. >> thanks in advance! >> nacho >> >> >> >> >> ----- >> Nacho >> Smalltalker apprentice. >> Buenos Aires, Argentina. >> -- >> View this message in context: >> http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858359.html >> Sent from the Cuis Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Cuis mailing list >> Cuis at jvuletich.org >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> > From 0800nacho at gmail.com Wed Oct 28 17:53:05 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 15:53:05 -0700 (PDT) Subject: [Cuis] New Commit: FileMan adoption and tweaks In-Reply-To: References: <562A812B.7090101@jvuletich.org> <20151023205016.afb1589149d0d8f0dd809bfa@Whidbey.com> <5630D8AE.8030803@jvuletich.org> <1446059935002-4858359.post@n4.nabble.com> Message-ID: <1446072785216-4858383.post@n4.nabble.com> Hannes, Thanks again so much! cheers Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-tp4857651p4858383.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From 0800nacho at gmail.com Wed Oct 28 18:26:28 2015 From: 0800nacho at gmail.com (nacho) Date: Wed, 28 Oct 2015 16:26:28 -0700 (PDT) Subject: [Cuis] VM Crashing when loading Themes pkg Message-ID: <1446074788550-4858389.post@n4.nabble.com> I'm trying to load the themes pkg using the latest Cuis image and every time I try to do it the VM crashes. I was using the last Cog vm from Eliot's place. I tried using previous vms but the result is the same. I've tried with other packages and the effect is the same: vm crashes. I'm in OSX 10.11.1 I attach the crash.dmp file Could it be due to the changes in the FM? Anyone is having the same crashes? Thanks Nacho crash.dmp ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/VM-Crashing-when-loading-Themes-pkg-tp4858389.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From juan at jvuletich.org Thu Oct 29 07:37:57 2015 From: juan at jvuletich.org (Juan Vuletich) Date: Thu, 29 Oct 2015 09:37:57 -0300 Subject: [Cuis] VM Crashing when loading Themes pkg In-Reply-To: <1446074788550-4858389.post@n4.nabble.com> References: <1446074788550-4858389.post@n4.nabble.com> Message-ID: <56321325.6080504@jvuletich.org> Hi Nacho, Please use Cog #3370 as indicated in https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/GettingStarted-UsingCommandline.md and other documentation there. Cheers, Juan Vuletich On 10/28/2015 8:26 PM, nacho wrote: > I'm trying to load the themes pkg using the latest Cuis image and every time > I try to do it the VM crashes. > I was using the last Cog vm from Eliot's place. I tried using previous vms > but the result is the same. > I've tried with other packages and the effect is the same: vm crashes. > I'm in OSX 10.11.1 > I attach the crash.dmp file > > Could it be due to the changes in the FM? > Anyone is having the same crashes? > Thanks > Nacho > > crash.dmp > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/VM-Crashing-when-loading-Themes-pkg-tp4858389.html > Sent from the Cuis Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Cuis mailing list > Cuis at jvuletich.org > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > From 0800nacho at gmail.com Thu Oct 29 07:52:39 2015 From: 0800nacho at gmail.com (nacho) Date: Thu, 29 Oct 2015 05:52:39 -0700 (PDT) Subject: [Cuis] VM Crashing when loading Themes pkg In-Reply-To: <56321325.6080504@jvuletich.org> References: <1446074788550-4858389.post@n4.nabble.com> <56321325.6080504@jvuletich.org> Message-ID: <1446123159957-4858467.post@n4.nabble.com> Thank you Juan! I tried a lot of vms but don't reached build 3370. And I should have read the documentation, sorry. best Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/VM-Crashing-when-loading-packages-tp4858389p4858467.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From Ken.Dickey at Whidbey.com Thu Oct 29 18:56:50 2015 From: Ken.Dickey at Whidbey.com (KenD) Date: Thu, 29 Oct 2015 16:56:50 -0700 Subject: [Cuis] ColorEditor updated Message-ID: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> Hi all, I updated Morphic-ColorEditor for simpler layout and font preferences updating. I also updated Morphic-Misc1 for font preferences update. Dan, note that the Morphic-ColorEditor uses #when:send:to: for updates. You can file it in and check senders. Bugs to /dev/null, er, I mean to me. ;^) Cheers, -KenD From 0800nacho at gmail.com Fri Oct 30 19:08:02 2015 From: 0800nacho at gmail.com (nacho) Date: Fri, 30 Oct 2015 17:08:02 -0700 (PDT) Subject: [Cuis] a simple method to change the wallpaper Message-ID: <1446250082444-4858760.post@n4.nabble.com> PasteUpMorph>>setBackgroundImage: aFilename "Sets the graphic file provided as a wallpaper" self runningWorld backgroundImageData: aFilename asFileEntry binaryContents. Then you go to the File List and copy the name of the file in the clipboard. Open a workspace: self runningWorld setBackgroundImage: '' screenshot.jpg ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/a-simple-method-to-change-the-wallpaper-tp4858760.html Sent from the Cuis Smalltalk mailing list archive at Nabble.com. From dnorton at mindspring.com Sat Oct 31 21:01:06 2015 From: dnorton at mindspring.com (Dan Norton) Date: Sat, 31 Oct 2015 22:01:06 -0400 Subject: [Cuis] ColorEditor updated In-Reply-To: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> References: <20151029165650.cf5f926bcb0d8978410d2522@Whidbey.com> Message-ID: <56357262.9599.2DA3199@dnorton.mindspring.com> On 29 Oct 2015 at 16:56, KenD wrote: > Hi all, > > I updated Morphic-ColorEditor for simpler layout and font > preferences updating. > > I also updated Morphic-Misc1 for font preferences update. > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for > updates. You can file it in and check senders. > I've done that and I see that messages to SystemChangeNotifier are not required in order to use the method. Also, the dependency mechanism itself uses #when:send:to:. Any object can use #when:send:to: because it is an Object instance method. So, should this be named a different mechanism or is it just a different use of the dependency mechanism? If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#Featu reComparison - Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: