- Pharo-dev - lists.pharo.org

Re: [Pharo-project] another little OB "bug"

by Lukas Renggli

I investigated PluggableListMorph and ListMorph, the problem you describe is there (likely this should be fixed in Pharo). In Name: OB-Morphic-lr.149 Author: lr Time: 11 October 2010, 10:17:53 am UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e Ancestors: OB-Morphic-lr.148 - more efficient fix for list updating I try to remember the current scroll position before updating any OB list, so I guess this works around the problem (indeed the UI feels better after the change). I am not sure if this fix is safe. It works well in my images, but it might break some assumption of Morphic and destroy your image in the worst case. Lukas On 10 October 2010 18:39, Lukas Renggli <renggli(a)gmail.com> wrote: > I am not sure if I understand your question correctly, but presumably > your method is too long or you have too many methods in one class or > protocol. OB punishes you for this :-) > > Lukas > > 2010/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no >> problem then ;) >> >> Suppose you are working with a method that it is in the half of the method >> pane of OB. Once you save it or run test on it for example, the "scroll" and >> the method pane is updated so that THAT method is first, above. And >> sometimes this is quite annoying for me. >> >> Cheers >> >> Mariano >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

Re: [Pharo-project] Xtreams port to Squeak - second wave

by Sven Van Caekenberghe

Hi Nicolas, You have been working quite quickly, great! I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. I have been trying some of the examples from the doc pages (google code project), this simple one still fails: ((1 to: 10) reading collecting: [:x | x * x]) rest The readline example is using the non-existing #slicer: method, this simpler version seems to work: |text| text := 'line1\line2\line3\line4' withCRs reading. text := text ender: [ :char | char = Character cr ]. text collect: [ :line | line rest ]. That is a documentation bug though. Sven On 10 Oct 2010, at 22:09, Nicolas Cellier wrote: > Hi again, > I now have ported two more packages > - Xtreams-Transforms > - Xtreams-Substreams > and their tests > > I did not have any portability problem with those... > But that's because I did not handle the Character encoder/decoder. > Consequently, I have 8 tests failing (the Base64 related tests) > Plus 4 other tests failing because of my poor implementation of > #after:do: (forking processes in a SUnit TestCase can't be that > obvious). > > Now, the easy part of the port (copy/paste) is almost ended. > Once we manage a compatible way to handle pragmas, PEG Parser should > port quite easily too. > > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) > - Character encoding/decoding > - Compression/Decompression > > If you think you can help in any of these, please tell. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by Fernando olivero

Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. ISSUE 2653. http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… I did a test, maybe a good start would be to see if its failing now. Fernando On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: > Hi Folks, > > Cuis doesn't include #autoEnclose, so I don't know how it should behave. > > Cheers, > Juan Vuletich > > Mariano Martinez Peck wrote: >> Guille, if I remember correctly (not sure), these new classes like >> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >> think he is in the mailing list but not read it so frequently. So, for >> this issues maybe you can cc'ed him. >> >> Cheers >> >> Mariano >> >> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> >> >> Here is the piece of code that's behaving weird >> >> TextEditor>>dispatchOn: >> >> ... >> ... >> char := aKeyboardEvent keyCharacter. >> openers := '([{'. >> closers := ')]}'. >> ( closers includes: char) ifTrue: [ self blinkPrevParen: >> char ]. >> result := self normalCharacter: aKeyboardEvent. >> (self class autoEnclose and: [ openers includes: char ]) >> not ifTrue: [ ^ result ]. >> suffix := closers at: (openers indexOf: char). >> paragraph text append: suffix asString. >> self moveCursor: [ : position | position ] forward: true >> specialBlock: [ : pos | "no special behavior" ] event: >> aKeyboardEvent . >> self userHasEdited. >> >> ------------------------------------- >> >> So, if I evaluate "TextEditor autoEnclose: false", it is stops >> behaving like that :) >> >> What should be the desired behavior? Having it configurable as it >> is today but fix the strange bracket adding? remove this behavior? >> I can't find now how ParagraphEditor did this. >> >> Guille >> >> >> On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito >> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Yes, the issue can be reduced to: >> >> open parenthesis (or brackets), then something else (anywhere >> in the editor). >> >> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com >> <mailto:marianopeck@gmail.com>> >> >> I detected a similar problem: >> >> once you type an opening parenthesis, and then something >> else, it adds a new one at the END of the code >> >> check http://code.google.com/p/pharo/issues/detail?id=2939 >> >> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> >> >> http://code.google.com/p/pharo/issues/detail?id=3069 >> >> if you type: >> >> [] -> []] >> >> () -> ()) >> >> {} -> {}} >> >> >> >> >> Bye! >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Getting my head around low space

by Max Leske

"There is not enough memory to give squeak the amount specified by the 'memory EMBED tag.". Additionally there's a "Premature end of file" error on the image and then the VM crashes (OS X crash dialog). Issuing the same commands with 1 GB memory works fine (no problems with the image). Interestingly I tried to run the task with 3.5 GB in a 5.7b1 VM over night and the low space warning popped up when the progress bar was have as far then when I ran into the same condition using the 4.2.5b1U VM and 1 GB... Any suggestions? I couldn't attach the VM statistics because of the lacking menu integration but if you tell me how to extract the statistics (supposing they are interesting...) I'll happily rerun the task and post the results. Max On 10.10.2010, at 23:47, John M McIntosh wrote: > > On 2010-10-10, at 2:00 PM, Max Leske wrote: > >> I had a first failure with 1 GB. I used the 4.2.5b1U VM. Setting the memory to anything above 1 GB would lead to an error message. I'm now trying the 5.7b1 VM with 3.5 GB. >> >> Max > > So what is the error message? > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

by StÃ©phane Ducasse

Thanks! and welcome back. Stef On Oct 11, 2010, at 7:16 AM, Sheridan Mahoney wrote: > I've just re-entered the Pharo world after a long(ish) absence, and wanted to report a > new bug submission; here's the breakdown: > > Pharo image: dev > Pharo core version: Pharo-1.1.1-- Latest update: #11414 > Virtual machine used: 4.0.3.2202 Unix VM > OS: Ubuntu Lucid Lynx 10.04 > Class browser used if applicable: SystemBrowser default > > Steps to reproduce: > 1. start pharo > 2. open a Shout workspace > 3. select the just-opened workspace > 4. Ctrl-right button to get the meta-click window > 5. select 'save morph in file' > 6. hit 'ok' to proffered name for file > 7. a message box comes up that reads 'please wait while objects are > counted'. > 8. shortly after that an error is generated: > 'Error: this context was not included in the ImageSegment' > > > I'm planning on doing more research, but wanted to get the issue reported. > > Cheers, > Sheridan > > PS - so far I really like 1.1.1 !!! Good work, gang! > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Xtreams port to Squeak - second wave

by mkobetic＠gmail.com

"Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) > - Character encoding/decoding I just published XtreamsDevelopment(387) with following changes: * abstracted Encoder out of encoded streams to allow implementing our own encodings. * Encoder.Encoders registers known encoders * Encoder.DialectEncoder provides a hook to access dialect specific encoders * added ASCIIEncoder implementing ASCII encoding portably * added VWEncoder wrapping VisualWorks StreamEncoders Obviously VWEncoder won't work in Squeak and should eventually move to a VW specific package. But at the moment it might be useful as an example of how to take advantage of the existing encoders in Squeak. I briefly looked at the Multilingual categories in Pharo and there seem to be quite a few encodings available through the TextConverter hierarchy. You've expressed some reservations about that, but it might be worth taking advantage of those at least initially. Anyway with the above there should be at least an #ascii encoder available for now.

Oct. 11, 2010

[Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

by Sheridan Mahoney

Oct. 11, 2010

[Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b12

by John M McIntosh

I've stuck a version (5.8b12) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b12.app.zip This is based on the latest Cog VM source (oct 10/10/10). Changes to the support logic: (a) Supply file create/mod times & size based on target of symbolic link versus the link file node. (b) Untrusted directory was set wrong, use same default value as 4.2.x VM ~/Library/Preferences/Squeak/Internet/My Squeak/ (c) There is no -pathenc option (d) Attempt to integrate changes into Cog branch to allow you to compile VM from the Cog branch. *** This does not work yet, 90% there, Eliot and I still have some pencil sharping to do... *** Now the big news is that I pushed a version of the Squeak Cog stack VM to the Apple App Store! It's rough, but it's a candidate for review by Apple's special App review committee. It does not have socket support and we are seeing if they allow us to move image/change files in and out of the Documents folder via a desktop machine. I should know more by next weekend. If accepted then I am looking to the Smalltalk community to help in building a viable image to allow people to edit source code on an iPad. Lastly, yes something broken in open/gl on os-x 10.4 I hope to look at the issue this week. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Oct. 11, 2010

Re: [Pharo-project] [vwnc] Xtreams port to Squeak - second wave

by Michael Lucas-Smith

On Oct 10, 2010, at 5:18 PM, mkobetic(a)gmail.com wrote: > Hi Nicolas, > > "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Hi again, >> I now have ported two more packages >> - Xtreams-Transforms >> - Xtreams-Substreams >> and their tests If you get Interpreting and Marshaling going we'll have ST-ST communication between Pharo<->Squeak<->VisualWorks with a fast binary protocol. I suspect some trickery will be required to deal with namespaces, as the protocol assumes 'full names' for classes when matching between the ends. Michael

Oct. 11, 2010

Re: [Pharo-project] Xtreams port to Squeak - second wave

by Levente Uzonyi

On Sun, 10 Oct 2010, mkobetic(a)gmail.com wrote: > Hi Nicolas, > > "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Hi again, >> I now have ported two more packages >> - Xtreams-Transforms >> - Xtreams-Substreams >> and their tests > > This is great! I loaded your code into Pharo 1.1 and things seem to be working quite well. There was a complaint about missing SharedQueue2, I just created a dummy subclass of SharedQueue with that name and things seemed to load fine. > XTRecyclingCenter seems to be subclass of XTWriteStream, it should be Object subclass, maybe a typo ? > >> I did not have any portability problem with those... >> But that's because I did not handle the Character encoder/decoder. >> Consequently, I have 8 tests failing (the Base64 related tests) > > I was thinking, we could implement just 'encoding: #ascii' quite easily, to make this reasonably usable at least for applications that are fine with that. We're actually contemplating about implementing our own encoders for Xtreams too. The VW ones are tied to the classic streams more than we like. You might have noticed some rather hairy parts in the encoding streams yourself, where we're trying to work around some of the issues it creates. The advantage of reusing the existing encoders was that there are quite a few of those available, so reimplementing all that would be a drag. But we can come up with a scheme where we can reimplement at least the common ones and in VW we can still preserve hooking into the old ones for the rest. I can give that a try on VW side in the meantime so you could get those for free. > >> Plus 4 other tests failing because of my poor implementation of >> #after:do: (forking processes in a SUnit TestCase can't be that >> obvious). > > I looked at this, and I think this is how #after:do: should look like: > > after: aDelay do: aBlock > "Evaluate the argument block delayed after the specified duration." > > | watchdog | > watchdog := [ > aDelay wait. > aBlock value. > ] newProcess. > watchdog priority: Processor userInterruptPriority. > watchdog resume. > > This would assume that the 2 tests calling #timeout:server:client: would use a Delay instance instead of a Duration, which I'd be fine with. However making that change doesn't quite get the tests running. It's blowing up with a DNU on the 'output close' bit in #terminate:server:client: with output being nil, which I'm having trouble figuring out. I can't find who could possibly be nilling it out. I'm somewhat struggling finding my way around the Pharo tools. The test seems to otherwise pass but the DNUs from the background process isn't nice. Also when I just click on the test in the TestRunner, I actually get four DNUs, not just one as I would expect. So I'm kinda stuck, not sure how to move forward without help from someone who knows his way around Pharo. > I also get odd failure from #testWriteCollectingMultipleBufferSize, which seems to run fine (against collection) when I run the equivalent in a workspace, but strangely fails when running via the #timeout:server:client: construct, i.e. when client and server run in separate processes. Hm, now that I think of it, they sure could fail if something preempts the client, server processes at the right moment. I'll have to rethink that again. These problems should be solved with the latest version of CoreTests. > >> Now, the easy part of the port (copy/paste) is almost ended. >> Once we manage a compatible way to handle pragmas, PEG Parser should >> port quite easily too. > > I wouldn't worry about the Parser stuff at this point. > >> Then, the harder work begins: >> - File/Socket/Pipe >> - Pointers (in External Heap) > > I wouldn't worry, about the external heap stuff either. It's neat, but probably not something many people will miss. > >> - Character encoding/decoding > > I'll see if I can help with this from the VW side. > >> - Compression/Decompression > > Is Zlib linked into the VM in Squeak too ? The compression streams are written directly against the ZLib API, so there aren't any VW specific dependencies other than how those calls are made. Similarly the crypto streams go directly against the EVP API in LibCrypto in OpenSSL, so as long as we can abstract over how those are called, the stream implementation should work as is. > >> If you think you can help in any of these, please tell. > > If you could compile a list of changes that you'd like us to adopt on the VW side, I'd certainly look at that. I did read your posts but it's not entirely clear what you'd like to handle on Squeak side and what on VW side. A fileout would be best to avoid any confusion, but a description is fine too. > > I'm also unclear about the become: discussion. Don't write streams in Squeak become: the underlying collection when they grow it ? No. Squeak uses direct pointers, so it doesn't have an object table, therefore #become: is very expensive. See the Storage Management section of http://ftp.squeak.org/docs/OOPSLA.Squeak.html for details. Levente > > Cheers, > > Martin > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010