May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Transcript needs your love

by stepharo

Thanks Clement. I think that this is true that we should take care about all the hidden behavior (like creating repo and others). Stef Le 11/5/15 17:02, ClÃ©ment Bera a Ã©crit : > > > 2015-05-11 13:06 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>>: > > > About the GTools, I am sure you know it but, you can disable them > and work with the good old Workspace and (Eye-)Inspector. > > > Yeah but I could not open the setting browser because you need to be > able to create a directory to do so and it didn't work. I could not > either run a Do-it. And EyeInspector also relies on several framework > so I don't know if it would have worked. > > The problem is that going to the point where you reach your bug can > take a while in debug VMs / the simulator, so having to open the image > form a working VM to change it and restarting the debug VM / simulator > takes a while and reduce your productivity greatly compared to a > squeak image. > > > BTW, how do Traits depend on the bytecode set? > > Through markerOrNil. It looks for methods that have the pattern (at > bytecode level): > > selector > ^ self traitConflict > > I will add a fix for that next week. I am doing the next slice on > things I found were not working in the new bytecode set such as traits. > > 2015-05-10 16:43 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com > <mailto:bera.clement@gmail.com>>: > > > > 2015-05-10 10:37 GMT+02:00 Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > >> On 10 May 2015, at 10:28, ClÃ©ment Bera >> <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> >> wrote: >> >> >> >> 2015-05-09 23:21 GMT+02:00 Tudor Girba >> <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: >> >> I do not think there are many people around here that >> would think that it is irrelevant if the Pharo VM can >> be developed in Pharo or not. Of course, it is >> important. >> >> So, the discussion should not go to challenge this >> direction, but rather in you telling us the use cases >> that you need supported. Please note that I did not >> say which exact code and how it should look like. I >> would be interested in learning about the use cases >> you have. I am quite certain that there are a number >> of ways to support them and when we work on GT it >> would be useful to have your use cases on our table. >> >> >> Well I need many lines to explain each point and there >> are many... I can talk here about a few points. Then I >> will deal with Esteban for most of them because it is >> difficult to explain without an interactive discussion. >> >> >> Let me explain the use cases for the Transcript for >> example. The issues in Pharo are: >> - The Transcript does not show the stream as it is printed. >> - The Transcript does not inherit from Stream and thus >> cannot print with all the methods implemented in Stream. >> - The Transcript does not allow the user to decorate the >> text with bold, italic or colors. > > sorryâ¦ you can do that with squeak's transcript? > > > Of course you can. > > Try short cut such as Cmd+ 6 or Cmd + 7. Else in the right > click menu those are the first 3 entries. And you can copy the > decorated text from Transcript to a Workspace. > > > I am not sure this was changed on purpose. (from my other posts > about text and fonts and my bug reports) I got the impression some > people did changes (for cleanup or other reasons) and > maybe don't know what they changed or didn't not find the time to > finish the cleanup: > > TextMorph righclick does not work anymore. > Some text emphasis on FT fonts dont work. > Some TextMorph halos don't work anymore. > > I don't think alls this was done on purpose. > > For the Transcript shortcuts for example, if we change > ThreadSafeTranscript to use > PluggableTextEditorMorph > instead of > PluggableTextMorph > > cmd+6/7/8/9/0 for changing emphasis/color > works again. > > > Great ! Well that's one thing that can be fixed easily then. Thanks > for looking into it. > > > nicolai > >> >> /Usecase 1: Debug printing methods:/ In the VM you have >> debug printing methods, for example, to print the call >> stack. These methods are used from the VM simulator, to >> output the string in the Transcript, and in gdb, to ouput >> the string in the commandline. The commandline >> (FileStream stdout in Pharo) and the Squeak Transcript >> have the same behavior. In Pharo, the Transcript does not >> inherit from Stream so you can't use the required stream >> methods to print the debug printing method on the >> Transcript. In addition, some printing methods print a >> lot of things and it is important to show the stream as >> it is printed. >> For this use-case, we want to keep the smallest >> difference between the gdb/commadline behavior and the VM >> simulator/Transcript behavior. If you implement advanced >> tooling in GT, you therefore need to implement gdb >> extensions (and lldb extensions because some of us use >> lldb instead of gdb) and maintain them. I don't think >> this is a solution. >> >> /Usecase 2: CCode generation debugging:/ The >> CCodeGenerator or Slang translator translates Slang code >> into C code. Sometimes there is a bug. To debug, instead >> of generating the faulty C method into an external C >> file, we print only the faulty C method in the >> Transcript. Again, we want to keep the lowest difference >> between the real usecase (printing on the C file) and the >> debug usecase (printing on the Transcript). In Squeak the >> FileStream and the Transcript are both Stream, everything >> works as expected. In Pharo the Transcript has not the >> expected behavior. Again the method can be long, you can >> have to wait several seconds, so you'd like the >> transcript to show the stream as you print it. >> >> /Usecase 3: VM simulation:/ Simulating the VM is quite >> slow, especially the machine code execution simulation. >> During the simulation process, the UI is non interactive >> and shows only every while what the simulator is doing in >> the Transcript. It is important as sometimes when >> debugging with a test at each machine code instruction it >> could take several hours before the UI is interactive >> again and you want to know what is going on. I don't >> complain that it takes several hours because the >> alternatives usually require days of debugging and we can >> launch the VM simulator overnight. In Pharo this does not >> work as expected. >> >> /Usecase 4: In-image machine-code compilation:/ While >> working in the JIT compiler, sometimes the machine code >> generated for a bytecoded method is faulty. A common way >> of debugging it is to print the machine code instructions >> of the machine code version of the method in the >> Transcript. It can take a while to print, so it is >> important to have the Transcript showing the text as it >> prints. Then, the easiest way of debugging is to look at >> the machine code and understand what is wrong. For this >> purpose, we add text decoration to color jump addresses >> or the instructions where the instruction pointer was >> when the VM crashed. Then, in squeak, we can easily copy >> the decorated text to a workspace and generate a new >> version of the machine code method and compare. In >> machine code, it is very difficult to do analysis to have >> more information than just the decompiled text. We add >> some information while simulating because we know for >> example the address of specific trampolines, therefore we >> can print the name of the trampoline when we see that its >> address is called. Again, sometimes we also have to debug >> in gdb. In this case, we disassemble the machine code and >> compare it to the one from in-image compilation, so both >> printed strings have to be similar (similar text, same >> chariot returns). >> >> >> >> Another example is the complexity of the Pharo tools: >> >> While developing the VM, I have sometimes a VM partially >> working or with some plugins not working. In the Squeak >> image, I can open a workspace on top of this half-working >> VM and run do-its to see what is working and what is not. >> In the Pharo image, I can't do anything. You can't open >> the workspace without opening more advanced tools. I >> tried to open the Playground, but the first time there >> was a bug with Traits (Playground use Traits somehow and >> they were not working due to the new bytecode set not >> being finished), when that first bug was fixed I could >> not open it because it crashed simply the VM (I believe >> it tried to access an external file such as >> playground-cache). Currently, the Pharo team is trying to >> build a set of basic tools that have few dependencies to >> debug a partially working system (that I think you will >> use to debug glamour while editing it, because you cannot >> use the glamour inspector if glamour is not working). >> That would solve this issue. >> But in no way this point is something that I can do alone >> to be able to develop the VM in Pharo. This has to be a >> community effort. And I am saying that because I can't be >> blamed not to work on the VM in Pharo if to do so I need >> to spend many months changing Pharo. >> >> >> >> An example that I believe is a problem in term of the >> community is the following: >> >> I added with Eliot the support for the new bytecode set. >> Currently, the Squeak image works with the new bytecode >> set but not the Pharo image. This is because only the >> Traits are broken, but this is something I could hardly >> figure out in the Pharo image because nothing is working >> as the GT tools use Traits. In Squeak I believe there are >> very few users of Traits so everything worked, and the >> test suite can reveal that the Traits are broken easily. >> >> Currently, the VM process to me is to first make new >> features work in Squeak, because it is simpler, and then >> make it work with Pharo, which is more complex. In the >> last section I discussed how Traits were a problem while >> implementing the new bytecode set. So what is the long >> term solution for this issue ? >> - Will we have a bootstrap process that creates first a >> Trait-free Kernel and then build the Pharo Kernel out of it ? >> - Do we forbid people to use Traits in the Pharo Kernel >> and does that make sense to have Traits in Pharo in this >> case ? >> - If we don't do anything, maybe the Traits are only a >> slight difference with low impact in most cases and it's >> fine. But maybe there are many small aspects like Traits, >> such as the Slots the way they were used in GT recently >> (I don't blame GT or anything, it was just using features >> in the system that created issues for me), and maybe we >> reached a point where the complexity between the Pharo >> kernel and the Squeak kernel is big enough so that a VM >> developer will first make Squeak works when introducing >> new features and then deals with the complexity of Pharo ? >> >> So, what do we do ? I don't see any simple solution for >> this issue. And I believe there are people around that >> see as the only solution for this issue not to have the >> Pharo VM development process in Pharo because they will >> see it as a threat to what they want to do with Pharo. >> >> >> >> Best Doru ! >> >> PS: I am still using the GTInspector with additional >> views on graphs created with Roassal everyday and I still >> enjoy it. >> >> PS2: I am on vacation currently because I was getting >> crazy looking at machine code all day long, so I may not >> answer as quick as usually during the next week. >> >> >> >> Cheers, >> Doru >> >> >> >> On Sat, May 9, 2015 at 9:31 PM, ClÃ©ment Bera >> <bera.clement(a)gmail.com >> <mailto:bera.clement@gmail.com>> wrote: >> >> >> >> 2015-05-09 20:25 GMT+02:00 stepharo >> <stepharo(a)free.fr <mailto:stepharo@free.fr>>: >> >> >> >> Le 9/5/15 20:16, ClÃ©ment Bera a Ã©crit : >>> This whole conversation here shows very well >>> the point that I tried to explain to Stef >>> last week. I'm sorry if the mail is a bit >>> long but I think this discussion has to be >>> done. >>> >>> My whole Smalltalk development life, I have >>> used Pharo and was happy with it. Now I am >>> also working in Cog's JIT compiler and for >>> this specific project, I am working with >>> Squeak. I don't work with Squeak because I >>> don't like Pharo, I told you before, I have >>> worked with Pharo on all my project before, >>> enjoyed it and if it was possible I would >>> use Pharo. I work with Squeak because the VM >>> development tool and development process >>> simply does *not* work in Pharo. This is not >>> only because of VM tools working with the >>> old Morphic not working anymore in Pharo or >>> details like that, it is also due to deeper >>> changes in Pharo. >>> >>> Stef believes it is important that Pharo is >>> able to host development for its own VM. >>> Therefore, I discussed with him and Esteban >>> about a first list of points that are >>> necessary for Pharo to support its VM >>> development in Pharo, which includes this >>> Transcript behavior. >>> >>> As of today, and I am honest here, I believe >>> that what is required for Pharo to support >>> the development process of its VM includes >>> points which goes in the opposite direction >>> than a few points in the Pharo roadmap, that >>> people in the Pharo community will see as a >>> regression, as "an intrusion from the Squeak >>> philosophy into Pharo", or as forbidding the >>> integration of features that breaks the VM >>> development process. Therefore, I believe >>> the Pharo community would disapprove to make >>> such changes and I highly doubt that it is >>> possible to have the development process of the >>> Pharo VM in Pharo. >>> >>> I was thinking that only a few points would >>> be a problem such as the increasing memory >>> footprint of the Pharo image that is going >>> to get worse with the sources that will be >>> included in the image in the future, whereas >>> a VM developer needs a small image (See >>> previous threads in this mailing list where >>> Hilaire complains about that for example). >> >> clement can I ask a simple question? >> why did I ask guille to work on minikernels >> and bootstrap for his phd instead on a topic >> where we can publish? >> - choice A: lack of idea >> - choice B: .... >> >> >> I have already stated that you believe that it is >> important that Pharo is able to host development >> for its own VM. >> >> I am not against what you did and I am very >> excited with Guille's work. >> >> Pharo is community-driven, so I am not asking the >> question to you only, but to the community. >> >> >>> However, I didn't think that even simple points >>> like the Transcript behavior discussed here, >>> which looks like to me as a regression and is >>> required for VM development, would be seen as an >>> improvement by a non negligible part of the >>> community. >>> >>> In this mailing-list, the whole Pharo community >>> is present and can see this discussion. So the >>> open questions are: >>> >>> *Do you want to have the development of the >>> Pharo VM in Pharo, or do you want the >>> development of the Pharo VM to remain in Squeak ?* >>> *Do you think a system that is not good enough >>> to handle its own VM development is a good system ?* >>> >>> I am not willing to go against the will of the >>> community because I enjoy community-driven >>> softwares. If the answer is that Pharo should be >>> able to support its own VM development then as I >>> started I will help Esteban and Stef to improve >>> Pharo so that it can support its own VM >>> development. Now, if the answer is that the >>> development of the Pharo VM should remain in >>> Squeak, I will continue developing the VM in >>> Squeak. >>> >>> You are the Pharo community, you are the ones >>> that make Pharo alive and kicking, so you tell >>> me what you think we should do. >>> >>> Clement >>> >>> 2015-05-09 18:23 GMT+02:00 Eliot Miranda >>> <eliot.miranda(a)gmail.com >>> <mailto:eliot.miranda@gmail.com>>: >>> >>> Hi Ben, >>> >>> On May 9, 2015, at 7:41 AM, Ben Coman >>> <btc(a)openinworld.com >>> <mailto:btc@openinworld.com>> wrote: >>> >>>> >>>> >>>> On Sat, May 9, 2015 at 10:09 PM, Ben Coman >>>> <btc(a)openinworld.com >>>> <mailto:btc@openinworld.com>> wrote: >>>> >>>> From my limited experience bug hunting, >>>> calling #changed: from a thread other >>>> than the UI thread is a source of >>>> evil. There are too many assumptions >>>> throughout the system that the UI is >>>> single threaded. Can anyone advise me >>>> that is not a proper belief? >>>> >>>> Then that implies that a Transcript >>>> implementation where #nextPut: direct >>>> calls #changed: >>>> is not appropriate for use with >>>> multi-threaded applications. In Pharo, >>>> #changed: is only called from >>>> #stepGlobal, which is called from >>>> doOneCycle:. (This came about as a >>>> last minute bug fix before Pharo 3 >>>> release and maybe could use some cleanup. >>>> >>>> Separating the UI from Transcript into >>>> its own viewer might be a good idea, >>>> but actually it would not solve Stef's >>>> case since his code would still be >>>> running in the UI thread -- unless the >>>> viewer ran in another thread, which >>>> would have its own complexities. >>>> >>>> I think the point about efficiency is >>>> significant. The following example... >>>> Time millisecondsToRun: [ 1000 >>>> timesRepeat: [ Transcript show: 'x' ] ] >>>> on Squeak 4.5 --> 12749ms >>>> on Pharo 50029 --> 2ms >>>> >>>> >>>> As a point of comparison, on VW 8.0 --> >>>> 43817ms >>>> and so you might guess, VW 8.0 outputs each >>>> 'x' immediately. >>>> cheers -ben >>> >>> Way to go, Squeak! Actually this is >>> disappointing. I'm rather frustrated with >>> Squeak's slow transcript, and was hoping >>> that VW would demonstrate it could be >>> faster. Looking at the Squeak implementation >>> I only see an obvious 30% or so improvement >>> via tuning. Looks like good performance will >>> take more work :-/ >>> >>> >>> >>> Eliot (phone) >>> >>> >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" >> >> > > > >

May 14, 2015

Re: [Pharo-dev] Transcript needs your love

by stepharo

Thanks alain for checking. I think that we can offer different implementations and let people pick the ones they like. My goal is to remove direct refer to Transcript from the image so that we can plug an implementation and in particular the merge of Doru and Norbert/Mine loggers Stef Le 14/5/15 15:12, Alain Rastoul a Ã©crit : > Le 14/05/2015 02:08, J. Vuletich (mail lists) a Ã©crit : >> A port of the code to Pharo is required, as Alain and Stef have shown. >> Besides, Cuis doesn't include support for Traits. I think your idea is >> very good, and I hope some Pharoer (Alain?) does it. > > Hi Juan, > > I tried Cuis, you did a very nice work here. > > About porting, I did this first raw port to allow other peoples who > complains about pharo transcript to have a look at Cuis Trancript more > easily. > And apart from a small window inset problem and an initial display > Form I probably did not get well (and/or a clip missing somewhere?), > it does the same thing than in Cuis. > > May be we should wait a little so that people can say their word about > it too and eventually/if they want/can/... investigate those two > morphic porting issues. > In the meanwhile, a simple "fix" in the Transcript could be done too > (see last Ben's post) with an extra system settings. > > About sluggishnesh and Transcript speedup , the changes you made in > Cuis, as seen in git commits, are a bit intrusive (DateAndTime, > AbstractFont, Strikefont ?), I don't think I know pharo enough to > report them. > > Also I experienced another issue that exits in Cuis too: > > The Transcript overwrite other morphs/windows when showing its > contents during do-it > > After end of execution, the world redisplays correctly > but not in Pharo > > (see attached screen shots) > >

May 14, 2015

Re: [Pharo-dev] Transcript needs your love

by stepharo

> How you gonna ensure that, when only tool that you have is a > completely single-minded (err.. threaded :) ) / thread unsafe Morphic > in your hands, that is absolutely dangerous to use outside UI thread > and recipe for disaster when fiddling with its state or interrupting > it at non-safe point? > Red morphs of death is actually a good sign of that, that Morphic has > little to offer to those, who dare to use multiple threads. > > Sometimes i thinking, would it be better to throw away all that > multi-threading crafts in VM and image, and make smalltalk *way more* > simpler and straight (like many other interpreted languages, that > don't have threads).. Because bulk majority 99.999% of our codebase > never using/deals with threading anyways. Besides, most of the people > finding multi-threading bizarre and confusing.. So, lets just throw it > away, no big loss. :) > > P.S. and i didn't meant to sound passionate, but rather sarcastic :) > Hi igor We were dicussing with camille and guille about what would be the impact on executing doits in separate threads. I'm really curious to see what we would get. Stef

May 14, 2015

Re: [Pharo-dev] Transcript needs your love

by stepharo

thanks alain did you publish a slice attached to the ug entry? Le 11/5/15 20:54, Alain Rastoul a Ã©crit : > Le 10/05/2015 13:15, Esteban Lorenzano a Ã©crit : >> >>> On 10 May 2015, at 13:10, stepharo <stepharo(a)free.fr> wrote: >>> >>> Why we cannot use the of Juan? >>> >>> > >> >> you can type in it, make do it, etc. (just like now) >> >>> > Hi Esteban, did you try it in pharo ? > > It took me some time to read this whole thread yesterday evening > back from WE, wow ... lot of posts... > and make a test today. > > (thanks to Clement explanations, the issue is more clear now. Indeed > it's a pity that vm development cannot be done in pharo too, > sometimes I really would like to have a look at it when I have > questions on internals). > > I tried to import Juan's source from the fogbugz post in pharo, > renaming Tranncript to CuisTranscript, > TranscriptMorph to CuisTranscriptMorph etc. > finally after some big red-death morph, and now a weird non-correctly > refreshing transcript > I wonder how good this solution fit in pharo morphic world ? > > It is somewhat hooked to morphic at low level and I had to import some > old deprecated methods from squeak > - since cuis doesn't start on my pc, I took them from squeak but may > be this is not good. > Also it will not solve the Elliot's editable and styling requirement. > > (Editable should be possible, but styling...? no clue) > > >

May 14, 2015

Re: [Pharo-dev] Trying to use Rubric in Nautilus ....

by stepharo

thanks Alain You rock :) When you visit us I would love to see if we could brainstorm on changs in Nautilus to remove the need for RubPluggable :) I would like to remove PluggableTextWithLimits and I would love also to deprecate TextMorph. Stef

May 14, 2015

Re: [Pharo-dev] Testers needed! Re: Athens BitBlt bug?

by Nicolai Hess

Thank you Ben, I think this is the information I was looking for. nicolai 2015-05-14 17:41 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > I can't follow all the details, but I dug up for a few references that > might relate... > > * [Vm-dev] There might be a bug in Bitblt copyloop > > http://lists.squeakfoundation.org/pipermail/vm-dev/2012-April/010303.html > > * BitBltSimulation>>copyLoop, read ahead memory failure. > > http://forum.world.st/BitBltSimulation-gt-gt-copyLoop-read-ahead-memory-fai… > > * [Squeakland] [BUG] Can't use Squeakland plugin very well from Firefox... > > http://lists.squeakland.org/pipermail/squeakland/2006-November/003380.html > Review 3.8.13.b3 > > * Macintosh release - source code change notes > http://wiki.squeak.org/squeak/5585 > Review 3.8.13.b3 > > * [pypy-commit] lang-smalltalk default: reverted the optimization to the > copyLoop because it introduced clipping errors (BTC: Strange that smalltalk > is mixing with pypy, so this might not relate at all) > https://mail.python.org/pipermail//pypy-commit/2013-April/073156.html > > cheers -ben > > > On Thu, May 14, 2015 at 5:22 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-05-08 22:28 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >> >>> >>> >>> On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>>> >>>> >>>> 2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>>> >>>>> >>>>> >>>>> On 8 May 2015 at 21:32, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>>> >>>>>>> >>>>>>> Some testers needed! >>>>>>> >>>>>>> I can not reproduce the BitBlt bug and I would like to get this >>>>>>> right, so that surface pattern >>>>>>> paints use the correct form dimension. >>>>>>> >>>>>>> Be sure, my fried, the bug is there, sitting in VM. >>>>>> Bitblt implementation prereads a pixel from bitmap *before* checking >>>>>> the loop bounds, meaning that it reads at least a single byte beyond the >>>>>> actual contents of the bitmap. >>>>>> It is not harmful in cases when bitmap is allocated in object memory >>>>>> since VM memory design actually guarantees, that there are at least certain >>>>>> amount of bytes in form of breathing space always available, so reading >>>>>> single word past any allocated object is not hurts.. >>>>>> But not in case, when bitmap residing in external heap.. because >>>>>> reading beyond allocated space might cause segmentation fault.. and it was, >>>>>> until i figured what was causing it and where the bug is. >>>>>> >>>>> >>>> This mean it can happen every time we read form data from a surface >>>> plugin - it is not only an issue for athens/cairo. >>>> >>>> Right, this is not cairo-only issue.. It just manifested itself when i >>> was started using external surfaces allocated by cairo with bitblt. >>> Which was causing occasional, irregular crashes time to time and i was >>> quite lucky finding the cause of it. >>> >> >> >> Any chance you remember what triggers this error? What code did you use, >> simple drawings or more advanced >> use of athens. Image patterns, gradient patterns. >> Or at least, what platform mac/win/linux? >> >> I tried different vm/image versions but only on windows so far. >> >> There were some changes on some bitblt functions, maybe the bug does not >> exist anymore? >> >> >> nicolai >> >> >>> >>> >>>> I will take a look at bitblt implementation. >>>> >>>> Thank you ! >>>> >>>> >>>>> >>>>>> >>>>> The workaround, that i introduced was simply to tell Cairo to allocate >>>>> surface 1 row taller and then use smaller height in bitblt operations, so >>>>> it can never use the last row.. >>>>> that, of course, going in conflict of using cairo for a patterns to >>>>> fill things with bitmaps, which relying on surface's dimensions and using >>>>> all its pixels.. >>>>> :( >>>>> >>>>> hmm.. >>>>> >>>>>> >>>>>> >>>>>>> Prefered test setup: >>>>>>> a (fresh) pharo image >>>>>>> load bleeding edge from Bloc (because with bloc the whole (morphic) >>>>>>> world is drawn with athens). >>>>>>> change to watery theme ( because it makes some heavy use of form >>>>>>> fills) >>>>>>> verify that vertical scrollbars have this artifact (blank lines). >>>>>>> load the attached code (this code reverts igors change for the 1 >>>>>>> pixel extra height. >>>>>>> >>>>>>> please report back >>>>>>> what platform windows/linux/mac 32/64 bit >>>>>>> what pharo vm and image version. >>>>>>> >>>>>>> For me >>>>>>> Windows 7 32 bit >>>>>>> Win32 built on Apr 9 2015 21:05:04 Compiler: 4.6.2 >>>>>>> Latest update: #50039 >>>>>>> >>>>>>> -> no segfault >>>>>>> >>>>>>> thanks in advance >>>>>>> >>>>>>> >>>>>>> 2015-03-13 21:22 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>>>>> >>>>>>>> I do not know. May be igor is reading this mailing-list but I >>>>>>>> doubt. >>>>>>>> >>>>>>>> >>>>>>>> 2015-01-27 21:46 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >>>>>>>> >>>>>>>> Anyone knows what this BitBlt bug is or was? >>>>>>>>> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row >>>>>>>>> missing >>>>>>>>> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra >>>>>>>>> height for Cairo surface >>>>>>>>> >>>>>>>>> Because with the fix in 13236, it is not (easily) possible to >>>>>>>>> make >>>>>>>>> a repeating (vertical) pattern paint with 1 pixel height: >>>>>>>>> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size >>>>>>>>> for Athens surface pattern paint from a Form >>>>>>>>> >>>>>>>>> >>>>>>>>> nicolai >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> BUMP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >

May 14, 2015

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

Nice to know. Thanks Gareth. On Thu, May 14, 2015 at 10:21 PM, Gareth Cox <gareth(a)inspired.org> wrote: > Just for fun, from VisualAge Smalltalk 8.6 > > "---------------------------------------------------------------------------------" > > Time millisecondsToRun: [1000 timesRepeat: [Transcript show: 'x']]. > VisualAge Smalltalk 8.6 --> 3120ms > > "---------------------------------------------------------------------------------" > > [ ($a value to: $h value) do: [ :c | > [ 1 to: 9 do: [ :i | > Transcript show: c asCharacter printString , i printString , ' '. > Processor yield > ] > ] forkAt: 6 > ]. > ] forkAt: 7. > VisualAge Smalltalk 8.6 --> > $h1 $g1 $f1 $e1 $d1 $c1 $b1 $a1 > $h2 $g2 $f2 $e2 $d2 $c2 $b2 $a2 > $h3 $g3 $f3 $e3 $d3 $c3 $b3 $a3 > $h4 $g4 $f4 $e4 $d4 $c4 $b4 $a4 > $h5 $g5 $f5 $e5 $d5 $c5 $b5 $a5 > $h6 $g6 $f6 $e6 $d6 $c6 $b6 $a6 > $h7 $g7 $f7 $e7 $d7 $c7 $b7 $a7 > $h8 $g8 $f8 $e8 $d8 $c8 $b8 $a8 > $h9 $g9 $f9 $e9 $d9 $c9 $b9 $a9 > > "---------------------------------------------------------------------------------" > > 1 to: 100 do: [ :i | > Delay forMilliseconds: 100. > Transcript show: 'x' > ] > VisualAge Smalltalk 8.6 --> Shows x every 100 milliseconds in the Transcript. > > "---------------------------------------------------------------------------------" > > > Hi guys > > the Transcript in Pharo is that it's not asynchronous so I can't use it > in VM development to show the current progress of the simulation. For > example: > 1 to: 100 do: [ :i | > 0.1 seconds asDelay wait. > Transcript show: 'x'. ] > => on Squeak, this shows a x every 0.1 second in the Transcript > => on Pharo, nothing happens during 10 seconds then all the x are shown. > https://pharo.fogbugz.com/default.asp?15515 > > -- > Gareth Cox > IT Manager/Developer > Inspired Org (PTY) Ltd >

May 14, 2015

Re: [Pharo-dev] Testers needed! Re: Athens BitBlt bug?

by Ben Coman

I can't follow all the details, but I dug up for a few references that might relate... * [Vm-dev] There might be a bug in Bitblt copyloop http://lists.squeakfoundation.org/pipermail/vm-dev/2012-April/010303.html * BitBltSimulation>>copyLoop, read ahead memory failure. http://forum.world.st/BitBltSimulation-gt-gt-copyLoop-read-ahead-memory-fai… * [Squeakland] [BUG] Can't use Squeakland plugin very well from Firefox... http://lists.squeakland.org/pipermail/squeakland/2006-November/003380.html Review 3.8.13.b3 * Macintosh release - source code change notes http://wiki.squeak.org/squeak/5585 Review 3.8.13.b3 * [pypy-commit] lang-smalltalk default: reverted the optimization to the copyLoop because it introduced clipping errors (BTC: Strange that smalltalk is mixing with pypy, so this might not relate at all) https://mail.python.org/pipermail//pypy-commit/2013-April/073156.html cheers -ben On Thu, May 14, 2015 at 5:22 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-05-08 22:28 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > >> >> >> On 8 May 2015 at 22:20, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> >>> 2015-05-08 21:42 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>> >>>> >>>> >>>> On 8 May 2015 at 21:32, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On 8 May 2015 at 00:43, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>> >>>>>> >>>>>> Some testers needed! >>>>>> >>>>>> I can not reproduce the BitBlt bug and I would like to get this >>>>>> right, so that surface pattern >>>>>> paints use the correct form dimension. >>>>>> >>>>>> Be sure, my fried, the bug is there, sitting in VM. >>>>> Bitblt implementation prereads a pixel from bitmap *before* checking >>>>> the loop bounds, meaning that it reads at least a single byte beyond the >>>>> actual contents of the bitmap. >>>>> It is not harmful in cases when bitmap is allocated in object memory >>>>> since VM memory design actually guarantees, that there are at least certain >>>>> amount of bytes in form of breathing space always available, so reading >>>>> single word past any allocated object is not hurts.. >>>>> But not in case, when bitmap residing in external heap.. because >>>>> reading beyond allocated space might cause segmentation fault.. and it was, >>>>> until i figured what was causing it and where the bug is. >>>>> >>>> >>> This mean it can happen every time we read form data from a surface >>> plugin - it is not only an issue for athens/cairo. >>> >>> Right, this is not cairo-only issue.. It just manifested itself when i >> was started using external surfaces allocated by cairo with bitblt. >> Which was causing occasional, irregular crashes time to time and i was >> quite lucky finding the cause of it. >> > > > Any chance you remember what triggers this error? What code did you use, > simple drawings or more advanced > use of athens. Image patterns, gradient patterns. > Or at least, what platform mac/win/linux? > > I tried different vm/image versions but only on windows so far. > > There were some changes on some bitblt functions, maybe the bug does not > exist anymore? > > > nicolai > > >> >> >>> I will take a look at bitblt implementation. >>> >>> Thank you ! >>> >>> >>>> >>>>> >>>> The workaround, that i introduced was simply to tell Cairo to allocate >>>> surface 1 row taller and then use smaller height in bitblt operations, so >>>> it can never use the last row.. >>>> that, of course, going in conflict of using cairo for a patterns to >>>> fill things with bitmaps, which relying on surface's dimensions and using >>>> all its pixels.. >>>> :( >>>> >>>> hmm.. >>>> >>>>> >>>>> >>>>>> Prefered test setup: >>>>>> a (fresh) pharo image >>>>>> load bleeding edge from Bloc (because with bloc the whole (morphic) >>>>>> world is drawn with athens). >>>>>> change to watery theme ( because it makes some heavy use of form >>>>>> fills) >>>>>> verify that vertical scrollbars have this artifact (blank lines). >>>>>> load the attached code (this code reverts igors change for the 1 >>>>>> pixel extra height. >>>>>> >>>>>> please report back >>>>>> what platform windows/linux/mac 32/64 bit >>>>>> what pharo vm and image version. >>>>>> >>>>>> For me >>>>>> Windows 7 32 bit >>>>>> Win32 built on Apr 9 2015 21:05:04 Compiler: 4.6.2 >>>>>> Latest update: #50039 >>>>>> >>>>>> -> no segfault >>>>>> >>>>>> thanks in advance >>>>>> >>>>>> >>>>>> 2015-03-13 21:22 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>>>> >>>>>>> I do not know. May be igor is reading this mailing-list but I doubt. >>>>>>> >>>>>>> >>>>>>> 2015-01-27 21:46 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >>>>>>> >>>>>>> Anyone knows what this BitBlt bug is or was? >>>>>>>> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row >>>>>>>> missing >>>>>>>> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra >>>>>>>> height for Cairo surface >>>>>>>> >>>>>>>> Because with the fix in 13236, it is not (easily) possible to make >>>>>>>> a repeating (vertical) pattern paint with 1 pixel height: >>>>>>>> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size >>>>>>>> for Athens surface pattern paint from a Form >>>>>>>> >>>>>>>> >>>>>>>> nicolai >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> BUMP >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

May 14, 2015

Re: [Pharo-dev] Transcript needs your love

by Gareth Cox

Just for fun, from VisualAge Smalltalk 8.6 "---------------------------------------------------------------------------------" Time millisecondsToRun: [1000 timesRepeat: [Transcript show: 'x']]. VisualAge Smalltalk 8.6 --> 3120ms "---------------------------------------------------------------------------------" [ ($a value to: $h value) do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' '. Processor yield ] ] forkAt: 6 ]. ] forkAt: 7. VisualAge Smalltalk 8.6 --> $h1 $g1 $f1 $e1 $d1 $c1 $b1 $a1 $h2 $g2 $f2 $e2 $d2 $c2 $b2 $a2 $h3 $g3 $f3 $e3 $d3 $c3 $b3 $a3 $h4 $g4 $f4 $e4 $d4 $c4 $b4 $a4 $h5 $g5 $f5 $e5 $d5 $c5 $b5 $a5 $h6 $g6 $f6 $e6 $d6 $c6 $b6 $a6 $h7 $g7 $f7 $e7 $d7 $c7 $b7 $a7 $h8 $g8 $f8 $e8 $d8 $c8 $b8 $a8 $h9 $g9 $f9 $e9 $d9 $c9 $b9 $a9 "---------------------------------------------------------------------------------" 1 to: 100 do: [ :i | Delay forMilliseconds: 100. Transcript show: 'x' ] VisualAge Smalltalk 8.6 --> Shows x every 100 milliseconds in the Transcript. "---------------------------------------------------------------------------------" > Hi guys > > the Transcript in Pharo is that it's not asynchronous so I can't use it > in VM development to show the current progress of the simulation. For > example: > 1 to: 100 do: [ :i | > 0.1 seconds asDelay wait. > Transcript show: 'x'. ] > => on Squeak, this shows a x every 0.1 second in the Transcript > => on Pharo, nothing happens during 10 seconds then all the x are shown. > > https://pharo.fogbugz.com/default.asp?15515 -- Gareth Cox IT Manager/Developer Inspired Org (PTY) Ltd

May 14, 2015

Re: [Pharo-dev] Transcript needs your love

by J. Vuletich (mail lists)

Hi Alain, Quoting Alain Rastoul <alf.mmm.cat(a)gmail.com>: > Le 14/05/2015 02:08, J. Vuletich (mail lists) a Ã©crit : >> A port of the code to Pharo is required, as Alain and Stef have shown. >> Besides, Cuis doesn't include support for Traits. I think your idea is >> very good, and I hope some Pharoer (Alain?) does it. > > Hi Juan, > > I tried Cuis, you did a very nice work here. Thanks. > About porting, I did this first raw port to allow other peoples who > complains about pharo transcript to have a look at Cuis Trancript > more easily. > And apart from a small window inset problem and an initial display > Form I probably did not get well (and/or a clip missing somewhere?), > it does the same thing than in Cuis. Cool. > May be we should wait a little so that people can say their word > about it too and eventually/if they want/can/... investigate those > two morphic porting issues. > In the meanwhile, a simple "fix" in the Transcript could be done too > (see last Ben's post) with an extra system settings. Sure. > About sluggishnesh and Transcript speedup , the changes you made in > Cuis, as seen in git commits, are a bit intrusive (DateAndTime, > AbstractFont, Strikefont ?), I don't think I know pharo enough to > report them. The only relevant changeset is 2321, in folder CoreUpdates (the DateAndTime changes are completely unrelated). The changes to Fonts are only to let #displayUnfinishedEntryOn: save the last updated X for the unfinished entry. This is needed to avoid overwriting stuff (the "bold" efeect you saw). This is a good optimization and it is the only relevant change. If you find a way to make #drawString:at:font:color: answer the x of the rightmost affected pixel, that is more amenable to Pharo, it would be equally useful. > Also I experienced another issue that exits in Cuis too: > > The Transcript overwrite other morphs/windows when showing its > contents during do-it > > After end of execution, the world redisplays correctly > but not in Pharo > > (see attached screen shots) In Cuis, the world repair is requested in the last line of #display, that reads self changed: #redraw "So any morph in front of us is repaired when Morphic cycles" This works because in #openTranscript, the Transcript is set as the model of the TranscriptWindow. An appropriate idiom for Pharo is needed here. > -- > Regards, > > Alain Cheers, Juan Vuletich

May 14, 2015