June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Bug in Open Workspace from File-Browser?

by Marcus Denker

> On 15 Jun 2015, at 09:02, stepharo <stepharo(a)free.fr> wrote: > > Marcus for certain application having a fileList is important. > You cannot ask your clients to use spotter to browse a file. > Please do not confuse the usage. > The idea is to re-use the inspector panes in the FileList. If you donât know that this is implemented like that you would never guess. Marcus

June 15, 2015

Re: [Pharo-users] Bug in Open Workspace from File-Browser?

by stepharo

Marcus for certain application having a fileList is important. You cannot ask your clients to use spotter to browse a file. Please do not confuse the usage. Stef Le 8/6/15 16:32, Marcus Denker a Ã©crit : > Maybe use > > Smalltalk tools workspace > > instead of the direct referenceâ¦ > > In the long run, for GT, people will use the the FileList less and > less and instead just use Spotter to explore the filesystem and then > GT to look at filesâ¦ > > We should try to replace the FileList by Spotter for Pharo5â¦ less code > to maintain. > > Marcus > >> On 07 Jun 2015, at 17:39, volkert <volkert(a)komponentenwerkstatt.de >> <mailto:volkert@komponentenwerkstatt.de>> wrote: >> >> I have found a bug and opened new case for it: >> https://pharo.fogbugz.com/f/cases/15711/ >> I also what to send a fix. >> But i am not sure, if the fix is as simple as i described it (see >> tail of this mail). >> My Question: Is the bug in the UIManager or only on the sender >> FileList>>viewContentsInWorkspace. I think, in the sender. So i can >> simply replace"UIManager default edit: aString label: 'Workspace from >> ', self reference basename " with " Workspace openContents: aString >> label: 'Workspace from ', self reference basename". >> >> Am 07.06.2015 um 17:20 schrieb stepharo: >>> UIManager was an attempt to support a way to theme widgets. >>> And also to be able to run Pharo headless but providing a DummyManager. >>> What is the original problem you faced? >>> >>> Stef >>> >>> >>> Le 6/6/15 16:37, volkert a Ã©crit : >>>> Is this change resonable. I have no idea, what the Design-Idea >>>> behind the UIManager what services is should provide. May be it >>>> make sense to have the extra services on UIManager, but think the >>>> bug is in FileList>>viewContentsInWorkspace and not in UIManager. >>>> >>>> ---- >>>> I propose for Workspace to change the current code: >>>> >>>> FileList>>viewContentsInWorkspace >>>> "View the contents of my selected file in a new workspace" >>>> | aString | >>>> self reference streamWritable: false do: [ :stream| >>>> aString := stream setConverterForCode contentsOfEntireFile ]. >>>> UIManager default edit: aString label: 'Workspace from ', self >>>> reference basename <----- WRONG >>>> >>>> to : >>>> >>>> FileList>>viewContentsInWorkspace >>>> "View the contents of my selected file in a new workspace" >>>> | aString | >>>> self reference streamWritable: false do: [ :stream| >>>> aString := stream setConverterForCode contentsOfEntireFile ]. >>>> Workspace openContents: aString label: 'Workspace from ', self >>>> reference basename >>>> >>>> And i also proposse the add a Playground case. >>>> >>>> New Method: >>>> >>>> FileList>>viewContentsInPlayground >>>> "View the contents of my selected file in a new playground" >>>> | aString | >>>> self reference streamWritable: false do: [ :stream| >>>> aString := stream setConverterForCode contentsOfEntireFile ]. >>>> GTPlayground openContents: aString label: 'Playground from ', >>>> self reference basename. >>>> >>>> and also FileList>>serviceViewContentsInPlayground and the case in >>>> ListList>>itemsForAnyFile. >>>> >>>> If ok, i can fix Workspace and add Playground menu to FileList, >>>> after i have figured out how to send an fix ;-) >>>> >>>> BW, >>>> Volkert >>>> >>>> Am 03.06.2015 um 16:40 schrieb Ben Coman: >>>>> Or do we now want such to open in Playground? >>>>> >>>>> btw, these are the relevant methods. >>>>> FileList>>FileList>>viewContentsInWorkspace >>>>> FileList>>viewContentsInWorkspace >>>>> >>>>> cheers -ben >>>>> >>>>> On Wed, Jun 3, 2015 at 6:57 PM, volkert<volkert(a)komponentenwerkstatt.de> wrote: >>>>>> The File Browser has a Context Menu "Workspace with Contents". It opens an >>>>>> Edit Window (String Morph), but not a Workspace ... >>>>>> >>>>>> Is the Menu-Title wrong or the implementation? >>>>>> >>>>>> BW, >>>>>> Volkert >>>>>> >>>> >>> >> >

June 15, 2015

Re: [Pharo-users] storeOn: and literal limits

by Sean P. DeNigris

stepharo wrote > storeOn: is old because it will not handle cycles and other. > So I would simply use Ston. I agree. I ran into two problems right away - internal references are not maintained and it's easy to hit the literal array limit. However, my use case is saving data in Pharo and loading it into Amber, and right now amber-ston is not in a usable state. So, #storeOn: has the unique advantage of saving as Smalltalk source code, and therefore requiring no external library support. So it's useful in simple cases/models where one won't hit those limits ----- Cheers, Sean -- View this message in context: http://forum.world.st/storeOn-and-literal-limits-tp4832255p4832337.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 14, 2015

Re: [Pharo-users] Copy array of float to GPU memory

by cheikhou

Hello Ronie. thanks for your response. >Sorry for the late answering. I needed to check some stuffs. no problem. >What kind of error are you getting? a NativeBoost error or incorrect results? Yes I were getting incorrect result. But when I use methods like asCLFloatArray and asFlotArrayFromCL it works. > For completeness, I just added the following new methods. Nice! I am sure that it makes OpenCL package more and more robust and enable friendly programming on GPU. >Unlike passing an IntegerArray or a FloatArray, these are method are creating a new array, looping over all >elements and doing marshalling/unmarshalling. These methods can be very inefficient. Be careful when >using them. Yes thanks a lot Ronie I will be careful to this. @Ben Cormas Look at this link http://forum.world.st/Using-VirtualGPU-td4826028.html ----- Cheikhou -- View this message in context: http://forum.world.st/Use-array-of-float-to-GPU-memory-tp4831970p4832335.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 14, 2015

Re: [Pharo-users] storeOn: and literal limits

by stepharo

storeOn: is old because it will not handle cycles and other. So I would simply use Ston. Stef Le 14/6/15 06:20, Sean P. DeNigris a Ã©crit : > Thierry Goubier wrote >> There is some code in SmaCC to handle that. > Would it make sense to extract? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/storeOn-and-literal-limits-tp4832255p4832324.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 14, 2015

Re: [Pharo-users] storeOn: and literal limits

by Thierry Goubier

Le 14/06/2015 06:20, Sean P. DeNigris a Ã©crit : > Thierry Goubier wrote >> There is some code in SmaCC to handle that. > > Would it make sense to extract? I'd try if it works for you first :) Code is there: https://github.com/ThierryGoubier/SmaCC/blob/d5371fbf3298fcf8a0053d5c122db7… https://github.com/ThierryGoubier/SmaCC/blob/90257788f495cc8bb3900f64115cca… https://github.com/ThierryGoubier/SmaCC/blob/90257788f495cc8bb3900f64115cca… Thierry

June 14, 2015

Re: [Pharo-users] storeOn: and literal limits

by Sean P. DeNigris

Thierry Goubier wrote > There is some code in SmaCC to handle that. Would it make sense to extract? ----- Cheers, Sean -- View this message in context: http://forum.world.st/storeOn-and-literal-limits-tp4832255p4832324.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 14, 2015

Re: [Pharo-users] If comments seperate from the source code and have your own comments

by Stephan Eggermont

On 13/06/15 20:35, lb wrote: > AnnoApp is a tool for writting your own comment for > Package\Tag\Class\Method. seperating from source code file. > Your own annotation can be save out as a file use AnnoEditor. > The output file can be read back to (new) image according the name of > Package\Tag\Class\Method if the names still in the (new version) image. > AnnoEdit can mark or delete the annotations that do not exist in the Image. Well done! Nicely integrated in Nautilus, and a nice separate editor. Stephan

June 13, 2015

Re: [Pharo-users] If comments seperate from the source code and have your own comments

by lb

Thank you Paul and Stepharo. AnnoApp is a tool for writting your own comment for Package\Tag\Class\Method. seperating from source code file. Your own annotation can be save out as a file use AnnoEditor. The output file can be read back to (new) image according the name of Package\Tag\Class\Method if the names still in the (new version) image. AnnoEdit can mark or delete the annotations that do not exist in the Image. for Pharo4.0, MCHttpRepository location: 'http://smalltalkhub.com/mc/LiangBing64/AnnoApp/main' user: '' password: '' Best Regarts! Liangbing At 2015-06-14 00:31:05, "Paul DeBruicker" <pdebruic(a)gmail.com> wrote: >Hi Liang, > >I like that adding Annos don't make the package with the code I'm annotating >dirty. > >How do I move Annos from one image to another? > >The help is in Chinese, is there anything there that a person would need >that they couldn't figure out from reading hte code? I found the >AnnoEditor, which seems nice. > > >Have you put this up on smalltalkhub yet? > > >Thanks for sharing > >Paul > > > > >BingLiang wrote >> Hi, >> >> >> I know the comment is very important for reading source code and it is >> also important to write your own comment after understand somethings. >> I created a rough annotation application----AnnoApp for Nautilus, please >> give me good advice to improve it. >> Attached are the monticello files. >> Thank you in advance! >> >> >> Liang >> >> >> PS >> I love Smalltalk and I love Pharo. >> >> >> >> >> >> AnnoApp-Pharo4.0.mcz (36K) >> <http://forum.world.st/attachment/4832260/0/AnnoApp-Pharo4.0.mcz> >> AnnoApp-Pharo5.0 50113.mcz (36K) >> <http://forum.world.st/attachment/4832260/1/AnnoApp-Pharo5.0%2050113.mcz> > > > > > >-- >View this message in context: http://forum.world.st/If-comments-seperate-from-the-source-code-and-have-yo… >Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

June 13, 2015

Re: [Pharo-users] storeOn: and literal limits

by Thierry Goubier

Le 13/06/2015 16:06, Sean P. DeNigris a Ã©crit : > Does anything exist to handle uses of #storeOn: that bump into the literal > limit? E.g. that splits the offending constructor method into several > methods? Thanks. There is some code in SmaCC to handle that. Thierry

June 13, 2015