- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Bernhard Pieber

Dear Smalltalkers, I am very happy to announce that the Styled Text Editor for the brand new Cuis 4.0 is now available on GitHub [1]. The Styled Text Editor was first presented by me at last year's ESUG in Edinburgh [2]. Thanks to ESUG the presentation was recorded [3]. The Styled Text Editor is a framework for rich text editing using styles as known from popular word processors like Apple Pages or Microsoft Word. It features paragraph and character styles, allowing easy text formatting using styles only. It is intended for applications where users need to work with good looking rich text in a simple and fast way. Rich text commonly refers to text with formatting information like different fonts, sizes, alignments, and emphasis. To make editing as simple as possible instead of individual formatting information end users apply styles to parts of the text. Editing is made fast by keyboard shortcuts for text navigation, selection, and styles selection. Where possible the feel of widely used rich text editors is supported. It includes many features like - numbered and bulleted list paragraph styles - support for images - multiple level undo and redo - text completion using various glossaries including a dictionary of English with about 166.000 words - RTF clipboard (on OS X VMs with the ClipboardExtendedPlugin) The Styled Text Editor is developed in Cuis with the plan to eventually port it to Squeak and Pharo. The development of the Styled Text Editor inspired many changes to Cuis itself, and It is the first package to use the brand new DVCS based development process for external packages for Cuis 4.0. The idea and funding was provided by me, Bernhard Pieber and my company Software Generation. The implementation was done by Juan Vuletich, the mastermind behind Cuis. Thanks Juan for the close cooperation. It was and still is great fun to work with you. We are looking forward to feedback from you. Fork it on GitHub [1], create issues and send us pull requests. ;-) Cheers, Bernhard Pieber [1] https://github.com/bpieber/Cuis-StyledTextEditor [2] http://www.esug.org/wiki/pier/Conferences/2011/Schedule-And-Talks/StyledTex… [3] http://www.youtube.com/watch?v=pUoVbvwspi8&list=PL813665D04A2E4C0A&index=7&…

April 21, 2012

[Pharo-project] [Ann] Cuis 4.0 is released!

by juanlists＠jvuletich.org

Hi Folks, Cuis 4.0 is available at http://www.jvuletich.org/Cuis/Index.html . This is a very important release. It's been over 10 months since Cuis 3.3, but all this time means that there are a lot of big news now. The biggest one is the public release of the Styled Text Editor, by Bernhard Pieber. Bernhard will do the announcement of this project himself, all I want to say is that Styled Text Editor is the driving force behind most of the new stuff in this release. I also want to add that I'm delighted to be able to work with Bernhard on his project, and that I'm more than happy with the wonderful effect this is having on Cuis itself. Check http://www.jvuletich.org/Cuis/CuisReleaseNotes.html . So, the main new features of this release of Cuis are the required support for External Packages. This is a very lightweight implementation of Packages, based on PackageInfo, but not on Monticello. Versioning is done with GitHub. Take a look at http://www.jvuletich.org/Cuis/CodeManagementInCuis4.html and http://www.jvuletich.org/Cuis/CuisAndGitHub.html . Full list of features (from the release notes): ----------------------------------------------------- - Package Support. Cuis 4.0 has a package implementation based on PackageInfo. Can be used with a Git repository (like GitHub) for package versioning. More info at "CodeManagementInCuis4" and "CuisAndGitHub". This infrastructure and process is used for the StyledTextEditor project, developed by Bernhard Pieber and Software Generation. - New handling of ChangeSets. The idea is to have only one "live" change set that automatically captures all changes done to the Cuis Core image. Changes to Packages go to separate ChangeSets. - UCompletion. A new implementation of Autocompletion for Smalltalk code. Activates with ctrl-space. Usually gives the selector desired as the first option. Some features are: = Sorts by last definition of selector (Methods recently saved go first), = Sorts appropriately all selectors matching entered prefix (no hardcoded limits, like 40 selectors matching 2 letters). = Restricts suggestions if receiver is Global, a Constant or a pseudo-variable. = Doesn't have an "expanded mode". Always shows relevant suggestions. = Not restricted to a set of previously selected packages. All the methods in the system are accounted for. = Very fast, thanks to an optimized Trie implementation. = Compact code. Relies on services by Trie (for storing and querying selectors) and Shout (for parsing incomplete methods). = Helps make Shout faster, by providing super fast queries of selector prefixes. = Can be used for other applications besides Smalltalk code. Currently used for an English glossary for StyledTextEditor. - Trie. Cuis 4.- includes a very optimized implementation of a Trie. Tries are dictionaries where keys are Strings. Lookups are extremely fast. Search for entries matching a prefix are extremely fast (O(1) regardless of the size of the collection). Addition and removals are quite fast too. Used for UCompletion, holding 11,000 selectors. Also used for an English spell checker (in the StyledTextEditor project) holding 166,000 words. In both cases use of memory is quite reasonable (3 and 5.4 bytes per character in average) and query speed is extremely fast. - Multiple level undo / redo in all text and code editors. - ClickNHalf+Drag to select words. TripleClick or DoubleClickNHalf+Drag to select paragraphs. Like most modern text editors and wordprocessors do. - Multiple text selection (with control+mouse). Like most modern text editors and wordprocessors do. - Lf. The newline character is no longer Character cr (ASCII code 13), but Character lf (ASCII code 10). This is the standard in Mac and Unix platforms, and the required convention for GitHub. All the code in the image has been converted. - cmd-w closes window below mouse pointer. cmd-< y cmd-> cycle through windows. - New "PostIt" like HoverHelp morphs. - Simplification / Redesign: Scrolling in Morphic (TransformMorph gone, etc). - Deep cleanup in Paragraph and paragraph display services in Canvas and DisplayScanner (now MorphicScanner). - MouseClickState refactor, to ease new gestures (ClickNHalf+Drag, DoubleClickNHalf+Drag, TripleClick). - Killed AbstractEvent hierarchy. Unified event subscribing, triggering and handling everywhere in Cuis. - More TextMorph cleanup. - Numeric enhancements done by nice and jmv, both on Squeak and Cuis. - Many minor enhancements, cleanups and bugfixes. - Updates to Squeak: Numerics, Network, and many others. I hope you enjoy this release of Cuis as much as Bernhard and I enjoyed working on it. As usual, comments, discussion, bug reports, kudos and donations are all welcome! Cheers, Juan Vuletich

April 21, 2012

Re: [Pharo-project] Pharo 1.4 Released

by Sean P. DeNigris

What a tremendous list of accomplishments!! I'm blown away every time I read it... Are there more detailed descriptions of these bullets? Specifically I'm interested in: Marcus Denker-4 wrote > > - Better primitive simulation > - Better headless support > - Better support for error at startup > - Search in tools > - Better search > -- View this message in context: http://forum.world.st/Pharo-1-4-Released-tp4570369p4576837.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 21, 2012

Re: [Pharo-project] InnoSetup was: RE: One-click Windows comment

by Schwab,Wilhelm K

Power to the Penguin! :) I will admit that one sore spot is the Gnome dust up. Shoot me, I really like Gnome 2.x, or have at least grown comfortable with it. KDE is a bit overdone for my tastes, so I'm probably going to land on Xubuntu. Overall, these are small annoyances compared to all the "fun" I left behind as I departed Windows. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of garduino [garduino(a)gmail.com] Sent: Saturday, April 21, 2012 10:15 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] InnoSetup was: RE: One-click Windows comment Schwab,Wilhelm K wrote > > As an aside, it's interesting to see the term "ActiveX" *still* being > used. This was something that MS was trying to kill a LONG time ago. I'm > increasingly glad that I started tuning them out and focusing on the > simple and reliable vs. getting wound up in every new "technology" they > tried to jam down my throat. I'm much happier on Linux. > Could not agree more with you! I can't understand how / why so many people/companies are using MS products, when the company proved lot of times that really don't care about its users and customers. -- View this message in context: http://forum.world.st/InnoSetup-was-RE-One-click-Windows-comment-tp4576268p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 21, 2012

Re: [Pharo-project] Late binding class names

by Pavel Krivanek

On Sat, Apr 21, 2012 at 7:01 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Pavel Krivanek-3 wrote >> >> you may look at WADynamicVariable from Seaside how >> to process such context specific globals. >> > > Thanks for the pointer... I checked it out, but Seaside is actually not > doing anything with the binding there. > > Sean > It does nothing with class bindings directly but it is maybe the cleanest way how to solve this kind of problem. However if you really need to switch classes, you may try to sent becameForward: during context switching in ProcessorSheduller. -- Pavel

April 21, 2012

Re: [Pharo-project] Unresponsive 1.4 image

by StÃ©phane Ducasse

I guess that we have a showstopper for 1.4 :) Because when I take 1.4 and modify a method in the implementor pane I can also freeze the systemâ¦. I will repeat it to be sure. Stef On Apr 21, 2012, at 2:01 AM, phil(a)highoctane.be wrote: > To freeze 1.4 on Win XP SP3, you can try this one out: > > | tm border | > tm := TextMorph new. > tm contentsWrapped: ''; > extent: 100 @ 20. > "this is the important stuff" > (border := AlignmentMorph newRow) position: 200 @ 200; > borderWidth: 1; > borderColor: Color black; > hResizing: #shrinkWrap; > vResizing: #shrinkWrap; > addMorph: tm. > "this just makes the TextMorph easier =to see" > World addMorph: border. > > Then fill in the TextMorph with some text and newlines. > > Then call the halos and resize the right corner for a while, especially letting it go out of screen at the bottom. > > The system will come unresponsive, not obey Cmd-. etc. > > Sometimes it comes back to life but most of the time I've got to kill the process. > > CogVM or StackVM make no difference. > > Maybe there is a huge GC going on but there is no memory display thing (manuia) anymore in 1.4 so I can't tell. > > Hope it helps. > > Phil > > > > 2012/4/20 Paul DeBruicker <pdebruic(a)gmail.com> > > Janko MivÅ¡ek wrote > > > > > > After Ctrl-C in command prompt there is no new PharoDebug.log. > > > > > > > > Instead of Crtl-C do you get anything if you find the process and kill it > with: > > kill -s SIGUSR1 <pid> > > ? > (assuming you're using Cog ) > > -- > View this message in context: http://forum.world.st/Unresponsive-1-4-image-tp4574693p4575089.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges >

April 21, 2012

[Pharo-project] Problem with implementors of

by StÃ©phane Ducasse

Hi ben I do not really understand but when I edit a method in the implementor code pane after the cancel accept discard dialog does not work and I cannot do anything. Stef

April 21, 2012

Re: [Pharo-project] Feedback about SmallLint

by Lukas Renggli

On 21 April 2012 14:00, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > 2) RBContainsRule is not clear for me. " 'Checks for the common code > fragment: "(aCollection detect: [:each | ''some condition''] ifNone: [nil]) > ~= nil". contains: can simplify this code to "aCollection contains: [:each | > ''some condition'']". Not only is the contains: variant shorter, it better > signifies what the code is doing.'" > That is not very true. #contains answers true or false, while > detect:ifNone:[] answers whatever, and in your example it is nil. So, the > answer will be different and hence it is not the same. Ok, in your example, > you compare after with == nil... but... I don't really see a use case. For > example, in my case it detected: > > classNamed: className > > Â Â Â ^ (migrations > Â Â Â Â Â Â detect: [:m | m sourceClassName = className ] > Â Â Â Â Â Â ifNone: [ ^ self globalClassNamed: className ]) > Â Â Â Â Â Â targetClass. Thank you for pointing out. I have previously seen similar issues with this rule. I committed an improved version that should return less false-positives, and that finds a few more related issues. > 3) RBLawOfDemeterRule: maybe you can exclude string concatenation?Â (#,) > because it detected a lot of messages like this: > signalWith: aGlobalName and: aSelector > Â Â Â ^ self signal: 'Method ', aGlobalName, '>>#', aSelector, ' not found.' > > Also, what about excluding messages like #asXXX. For example, here it > detected "self signature asByteArray". Is that completly breaking the law of > demeter? mmm I don't think so. > > verifySignatureFrom: aDecoder > > Â Â Â | streamSignature | > Â Â Â streamSignature := ByteArray new: self signature size. > Â Â Â aDecoder nextEncodedBytesInto: streamSignature. > Â Â Â (self signature asByteArray = streamSignature) ifFalse: [ > Â Â Â Â Â Â FLBadSignature > Â Â Â Â Â Â Â Â Â signalCurrentSignature: self signature > Â Â Â Â Â Â Â Â Â streamSignature: streamSignatureÂ ]. Arguably this is a problem in your code: You could for example use streams or a formatter to build complicated strings; and you could ask the signature if it is the same as a stream signature. It is kind of arbitrary from when on a chain of selectors is considered a violation of the law of demeter ... Maybe the number should be higher? Maybe this number should be even different if these are unary, binary or keyword messages? As with any violation this is just a suggestion. > 4) RBSentNotImplementedRule:Â I didn't understand why it has selected: > > largeIdentityHash > > Â Â Â <primitive: 75> > Â Â Â self primitiveFailed > > both messages are implemented :( The rule checks if self-sends are implemented in the class hierarchy, and if super-sends are implemented in the superclass hierarchy of the method. For example, when you inherit from ProtoObject then #primitiveFailed is not implemented. In your case the problem might never show up in practice -- for example because your class is abstract and all subclasses implement the message; or because you use #doesNotUnderstand: -- but still I think the rule is correct. > 5) RBClassInstVarNotInitializedRule could be smarter and search not only for > #initialize but for #initializeXXX. Lots of times, I initialize my objects > with data, using a particular nitialize method, such as: > initializeWithBehaviors: someBehaviors extensionMethods: > someExtensionMethods > so the rule says there is no initialize...but I have that one ;) The rule only checks for the presence of an #initialize method (the only method that is automatically called by the system upon loading of a class) if the class defines variables. It does not check if (and where) the variable is actually assigned. Now if you have classes initialize each other or if you initialize your variables lazily that rule complains. I agree with the author of the rule that this is bad style and worth to think about. > That's all the feedback so far. It helped me to find some things to improve > so thanks! Please don't call it "SmallLint". Since at least 2003 the tool is called "Smalltalk Code Critics", see for example http://www.cincomsmalltalk.com/blog/blogView?entry=3236371324. I think it has been renamed even before 2000, but I can't find the slides of John anymore. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 21, 2012

Re: [Pharo-project] Unresponsive 1.4 image

by StÃ©phane Ducasse

janko open an issue with such cases so that we do not forget it. Stef On Apr 21, 2012, at 2:54 PM, Janko MivÅ¡ek wrote: > Hi guys, > > This code reproduces the blockade in fresh 1.4 OneClick (with or without > Transcript window open): > > [ > (Delay forSeconds: 5) wait. > SmalltalkImage current saveSession. > ] forkAt: Processor userBackgroundPriority > > Note that fork on default priority does not block while on user > background priority it blocks. It does not always block immediately > (sometimes yes sometimes not) but it after image restart it is always > blocked. > > But if you periodically write to Transcript from process on user > background priority, it does not block, even if you heavily browse > around, write to transcript, do manual snapshot: > > [ [true] whileTrue: > [(Delay forMilliseconds: 500) wait. > Transcript show: '.tst.'] > ] forkAt: Processor userBackgroundPriority > > So, it seems not only thread-safe Transcript but something with snapshot > (from a background priority, why?) is in play here. > > SmalltalkImage>>snapshot:andQuit: , shouldnât run it on highest priority > to block all other processes during the preparation for snapshot? > > Hope this helps a bit more > Janko > > > > Dne 21. 04. 2012 11:48, piÅ¡e Igor Stasenko: >> So, this is related to thread-safe transcript code.. >> which using semaphore to synchronize access to transcript stream. >> I guess what happens is that a semaphore is blocked in another >> process, but for some strange reason never released. This leads to >> situation, that any other process which will attempt to write to >> transcript will be blocked as well.. forever. > > Why is input not blocked immediately but after image restart? > > > More investigation: > > > 1. correction: image blocks in any case after restart, regardless if > there is additional writing to Transcript or not. Snapshot namely writes > to Transcript by itself and this is enough to block. > > 1. even if Transcript is closed the image blocks after restart > > This simulated snapshot from the background does NOT block after restart: > > [ > (Delay forSeconds: 5) wait. > SmalltalkImage current saveSession. > ] fork > > This one also not: > > [ | elapsed | > (Delay forSeconds: 5) wait. > elapsed := Time millisecondsToRun: > [SmalltalkImage current saveSession]. > Transcript show: ' in ', (elapsed // 1000) printString, 's '. > ] forkAt: Processor userBackgroundPriority > > > > > > >> >> 2012/4/21 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: >>> Hi guys, >>> >>> It seems that writing to Transcript from background process causes my >>> freeze after restart. And yes, I have Transcript window open. >>> >>> This is a code snippet in question: >>> >>> AIDASite class>>imageSnapshot >>> ... >>> elapsed := Time millisecondsToRun: >>> [SmalltalkImage current saveSession]. >>> Transcript show: ' in ', (elapsed // 1000) printString, 's '. >>> >>> >>> If I comment out the last line, snapshot doesn't block the image after >>> restart. >>> >>> This is not necessary 1.4 specific problem, because I noticed similar >>> problem in 1.3 also. Just that on 1.3 input freezes immediately while on >>> 1.4 it freezes after restart. >>> >>> Let me investigate a bit further, what if Transcript window is not open? >>> >>> Best regards >>> Janko >>> >>> >>> >>> Dne 20. 04. 2012 21:42, piÅ¡e StÃ©phane Ducasse: >>>> Ok may be nautilus bug. It should be different than janko problem. >>>> >>>> Stef >>>> >>>> On Apr 20, 2012, at 9:39 PM, Sean P. DeNigris wrote: >>>> >>>>> >>>>> StÃ©phane Ducasse wrote >>>>>> >>>>>> on which os? >>>>>> >>>>> >>>>> Mac Lion 10.7.3 >>>>> >>>>> -- >>>>> View this message in context: http://forum.world.st/Unresponsive-1-4-image-tp4574693p4575049.html >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

April 21, 2012

Re: [Pharo-project] Unresponsive 1.4 image

by StÃ©phane Ducasse

thanks I'm currently checking some strange behavior with mroph properties. Stef On Apr 21, 2012, at 2:01 AM, phil(a)highoctane.be wrote: > To freeze 1.4 on Win XP SP3, you can try this one out: > > | tm border | > tm := TextMorph new. > tm contentsWrapped: ''; > extent: 100 @ 20. > "this is the important stuff" > (border := AlignmentMorph newRow) position: 200 @ 200; > borderWidth: 1; > borderColor: Color black; > hResizing: #shrinkWrap; > vResizing: #shrinkWrap; > addMorph: tm. > "this just makes the TextMorph easier =to see" > World addMorph: border. > > Then fill in the TextMorph with some text and newlines. > > Then call the halos and resize the right corner for a while, especially letting it go out of screen at the bottom. > > The system will come unresponsive, not obey Cmd-. etc. > > Sometimes it comes back to life but most of the time I've got to kill the process. > > CogVM or StackVM make no difference. > > Maybe there is a huge GC going on but there is no memory display thing (manuia) anymore in 1.4 so I can't tell. > > Hope it helps. > > Phil > > > > 2012/4/20 Paul DeBruicker <pdebruic(a)gmail.com> > > Janko MivÅ¡ek wrote > > > > > > After Ctrl-C in command prompt there is no new PharoDebug.log. > > > > > > > > Instead of Crtl-C do you get anything if you find the process and kill it > with: > > kill -s SIGUSR1 <pid> > > ? > (assuming you're using Cog ) > > -- > View this message in context: http://forum.world.st/Unresponsive-1-4-image-tp4574693p4575089.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges >

April 21, 2012