Vm-dev May 2020

vm-dev@lists.squeakfoundation.org

39 participants
130 discussions

interpret loop termination and localIP
by K K Subbu 20 May '20

20 May '20

Hi, In CogVMSimulator>>interpret method: ----- self fetchNextBytecode. [true] whileTrue: [self assertValidExecutionPointers. atEachStepBlock value. "N.B. may be nil" self dispatchOn: currentBytecode in: BytecodeTable. self incrementByteCount]. localIP := localIP - 1. "undo the pre-increment of IP before returning" ----- Under what conditions will the loop terminate? If it terminates, the following statement assumes that the last instruction was a single-byte bytecode and no extended multi-byte instructions were involved. Is this fortuitous or by design? Thanks and Regards .. Subbu

1 0

Years ago, when mentioned initialize superclasses f(); where two misplaced and two thrown
by Janko Korelc 19 May '20

19 May '20

on pasteUpMorph one was assumed to go retrieve code from .. or should be sticky probably.. On Tue, 19 May 2020 at 10:15, <vm-dev-request(a)lists.squeakfoundation.org> wrote: > Send Vm-dev mailing list submissions to > vm-dev(a)lists.squeakfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > or, via email, send a message with subject or body 'help' to > vm-dev-request(a)lists.squeakfoundation.org > > You can reach the person managing the list at > vm-dev-owner(a)lists.squeakfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Vm-dev digest..." > > > Today's Topics: > > 1. Re: Win64 Builds broken, slow build times? (Marcel Taeumel) > 2. Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk > voidCogVMState. So. (Janko Korelc) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 May 2020 08:39:53 +0200 > From: Marcel Taeumel <marcel.taeumel(a)hpi.de> > To: <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] Win64 Builds broken, slow build times? > Message-ID: <Mailbird-6e410cd3-a26d-4a7d-8774-8735eddf3f82(a)hpi.de> > Content-Type: text/plain; charset="utf-8" > > Hi Eliot, hi Tom, > > I reported this issue about a week ago: > https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498 [ > https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498] > > > Bintray version squeak.cog.spur_win64x64_202005170205 is still broken. > Segfaults on startup. > > Best, > Marcel > Am 19.05.2020 01:02:06 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Tom, > > > > On May 18, 2020, at 1:44 PM, Tom Beckmann wrote: > > > > > > Hi everyone, > > > > I just tried building build.win64x64/squeak.cog.spur on the Cog branch > but got a segfault on startup. I then tentatively went back 10 commits > (HEAD~10) and it worked again. This is the output I received in gdb: > > > > Thread 1 received signal SIGSEGV, Segmentation fault. > > 0x00000000004016f3 in interpret () at > ../../spur64src/vm/gcc3x-cointerp.c:2809 > > 2809 memset(theStackMemory, 0, stackPagesBytes); > > (gdb) bt > > #0 0x00000000004016f3 in interpret () at > ../../spur64src/vm/gcc3x-cointerp.c:2809 > > #1 0x000000000052c34c in sqMain (argc=2, argv=0x1dd53a0) at > ../../platforms/win32/vm/sqWin32Main.c:1709 > > #2 0x000000000052c7f2 in WinMain (hInst=0x400000, hPrevInstance=0x0, > lpCmdLine=0xfc437c > "../../../Squeak6.0alpha-19582-64bit-202003021730-Windows/Squeak6.0alpha-19582-64bit.image", > nCmdShow=10) at ../../platforms/win32/vm/sqWin32Main.c:1802 > > #3 0x00000000004013c7 in __tmainCRTStartup () at > /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:339 > > #4 0x00000000004014cb in WinMainCRTStartup () at > /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:195 > > > > The main reason I'm writing, however, is that I only haven't done a > bisect yet because building the VM appears unusually slow, when compared to > building on Linux, as in, orders of magnitude slower. I believe I have the > same setup as we do on appveyor on windows using cygwin64. Incremental > builds seem to recompile a lot of files and it appears there are race > conditions when building with multiple threads (-j8). Are these known > limitations of the Windows build or am I potentially just having the wrong > setup? > > I hope it is simply wrong setup. I have been making these commits in > recent weeks in the context of getting 64-bit Terf working. Terf is 3D > ICC’s Croquet-derived business communications tool which was formerly known > as Teleplace and Qwaq forums and was the context in which OpenSmalltalk-vm > was conceived. > > I am building 64-bits using Clang 10 and MSVC and I assure you this works. > See HowToBuild for how to build using this configuration. > > Your configuration may be obsolete or it may be valid, and if valid we > should fix it. Can you list exactly what versions of software (Cygwin or > mingw, gcc, clang) you’re using your build? > > > > Thank you for any pointers! > > Tom > > Eliot > _,,,^..^,,,_ (phone) >

1 0

Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState. So.
by Janko Korelc 19 May '20

19 May '20

On Tue, 19 May 2020 at 08:22, <vm-dev-request(a)lists.squeakfoundation.org> wrote: > Send Vm-dev mailing list submissions to > vm-dev(a)lists.squeakfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > or, via email, send a message with subject or body 'help' to > vm-dev-request(a)lists.squeakfoundation.org > > You can reach the person managing the list at > vm-dev-owner(a)lists.squeakfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Vm-dev digest..." > > > Today's Topics: > > 1. Re: [Pharo-dev] Squeak and Pharo speed differences (Shaping) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 May 2020 01:21:53 -0500 > From: "Shaping" <shaping(a)uurda.org> > To: "'Pharo Development List'" <pharo-dev(a)lists.pharo.org>, "'Open > Smalltalk Virtual Machine Development Discussion'" > <vm-dev(a)lists.squeakfoundation.org> > Subject: Re: [Vm-dev] [Pharo-dev] Squeak and Pharo speed differences > Message-ID: <03c401d62da5$ca7b4ba0$5f71e2e0$(a)uurda.org> > Content-Type: text/plain; charset="utf-8" > > Another GUI-input speed observation: > > > > If you click the scroll wheel once to shift the text contents of the pane, > the visual effect is very fast. I cannot detect any latency; it certainly > is not close to what I see for text insertion/deletion, cursoring, and > double-click selection. The slower operations all involve getting a damage > rect at a specific point based on cursor position or click position. The > faster scrolling function doesn’t need to do that. It just grabs the > entire visible rectangle minus one line, and blits it shifted down by one > line, along with the one new line. That looks like an almost zero-cost > collection of damage rects. It’s a simple, fast calculation. Collection > of damage rects for the slower operations looks much more expensive. The > events involved in both cases are delivered to the target handler with the > same latency. The slowness or quickness seems to have after that. > > > > > > Shaping > > > > Hence graphics output necessarily lags input on Morphic. So these speed > differences have nothing to do with vm performance and everything to do > with GUI architecture. > > > > Both Squeak and Pharo show the same delay for text selection latency. > The architecture difference is not likely causing that. > > > > Given that both Pharo and Squeak useorphic and hence nothing have the same > tender-in-step architecture isn’t the fact that they show the sane > performance issue evidence that points to precisely this being the cause? > > > > Yes, but not architecture, by which I think you mean the pushing of events > versus the fixed-frequency regular loop in Morphic. I would expect a big > variation in the Morphic case, but I don’t know what the fixed frequency > is; it could well under the noise floor. My first thought would be that > getting the damage rects is the problem, but I’ve not seen the code. > > > > How do we index or look up the word rectangle to render? I’m think that > is more likely the cause. Is a map created at method compile time and > updated after text is moved during edits? > > > > My understanding is that damage rectangles are retrieved, > > > > Right, but this is the potentially slow part—the retrieving or perhaps > more specifically mapping a point to a rectangle containing a contiguous > sequence of non-whitespace character (a word). > > > > combined to produce a smaller (non-overlapping?) set, and that the entire > morph tree is asked to render within these damage rectangles. You can read > the gods for yourself. > > > > It’ll be a while. > > …. > > > > I just tried some new experiments. I should have thought of these > earlier. Character insertion and cursoring in any direction by one > character have the same latency. Collecting the damage rectangle at the > cursor position and around the selected word are both taking about the same > time as far as I can tell with my eye, and this time is longer than in VW > or any Windows app. But VW doesn’t use the Windows message queue > directly. All incoming Windows events are converted to Smalltalk > equivalents and are queued on the Smalltalk side. And it works well. Why > not mimic that pattern to get the extra speed? Does something in > Squeak/Pharo architecture prevent us from doing that? > > > > How do we set a multi-process time profiler running so that we don’t need > to eval blocks to get tallies. I just want to use the editor and watch > method hit distribution. I see the Time profiler window; it seems to need > a code snippet to work. > > > > > > How is the JIT code cache cleared? > > > > Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState. > > > > Okay. > > > > > > Can’t remember how it’s done in VW. > > > > CompiledMethod allInstancesWeakly do: [:compiledMethod | compiledMethod > flushCachedVMCode] > > > > > > Baseline state: the only thing that comes to mind here is Collect All > Garbage. > > > > There’s also Smalltalk garbageCollectMost which just runs a scavenge. > IIRC someInstance has a side effect of running a scavenge in VW. > > > > Okay. > > > > > > and then ensure, through the relevant introspection primitives, > > > > What are these? What state features am I introspecting after the test? > Sizes of heap subspaces? I can do Time microsecondsToRun: on the blocks. > > > > In Squeak/Pharo/Cuis see Smalltalk vmParameterAt: or Smalltalk vm > parameterAt: and senders. > > > > Okay. I see this list: > > > > parameterAt: parameterIndex > > "parameterIndex is a positive integer corresponding to one > of the VM's internal > > parameter/metric registers. Answer with the current value > of that register. > > Fail if parameterIndex has no corresponding register. > > VM parameters are numbered as follows: > > 1 end (v3)/size(Spur) of old-space (0-based, > read-only) > > 2 end (v3)/size(Spur) of young/new-space > (read-only) > > 3 end (v3)/size(Spur) of heap (read-only) > > 4 nil (was allocationCount (read-only)) > > 5 nil (was allocations between GCs > (read-write) > > 6 survivor count tenuring threshold > (read-write) > > 7 full GCs since startup (read-only) > > 8 total milliseconds in full GCs since > startup (read-only) > > 9 incremental GCs (SqueakV3) or scavenges > (Spur) since startup (read-only) > > 10 total milliseconds in incremental GCs > (SqueakV3) or scavenges (Spur) since startup (read-only) > > 11 tenures of surving objects since startup > (read-only) > > 12-20 were specific to ikp's JITTER VM, now 12-19 are open > for use > > 20 utc microseconds at VM start-up (actually at > time initialization, which precedes image load). > > 21 root table size (read-only) > > 22 root table overflows since startup (read-only) > > 23 bytes of extra memory to reserve for VM > buffers, plugins, etc (stored > > in image file header). > > 24 memory threshold above which shrinking object > memory (rw) > > 25 memory headroom when growing object memory > (rw) > > 26 interruptChecksEveryNms - force an > ioProcessEvents every N milliseconds (rw) 27 number of times > mark loop iterated for current IGC/FGC (read-only) includes > ALL marking > > 28 number of times sweep loop iterated for > current IGC/FGC (read-only) > > 29 number of times make forward loop iterated > for current IGC/FGC (read-only) 30 number of times compact > move loop iterated for current IGC/FGC (read-only) > > 31 number of grow memory requests (read-only) > > 32 number of shrink memory requests (read-only) > > 33 number of root table entries used for current > IGC/FGC (read-only) > > 34 number of allocations done before current > IGC/FGC (read-only) > > 35 number of survivor objects after current > IGC/FGC (read-only) > > 36 millisecond clock when current IGC/FGC > completed (read-only) > > 37 number of marked objects for Roots of the > world, not including Root Table entries for current IGC/FGC > (read-only) > > 38 milliseconds taken by current IGC (read-only) > > 39 Number of finalization signals for Weak > Objects pending when current IGC/FGC completed (read-only) > > 40 BytesPerOop for this image > > 41 imageFormatVersion for the VM > > 42 number of stack pages in use > > 43 desired number of stack pages (stored in > image file header, max 65535) > > 44 size of eden, in bytes > > 45 desired size of eden, in bytes (stored in > image file header) > > 46 machine code zone size, in bytes (Cog only; > otherwise nil) > > 47 desired machine code zone size (stored in > image file header; Cog only; otherwise nil) > > 48 various header flags. See getCogVMFlags. > > 49 max size the image promises to grow the > external semaphore table to (0 sets to default, which is 256 > as of writing) > > 50-51 nil; reserved for VM parameters that persist in the > image (such as eden above) > > 52 root table capacity > > 53 number of segments (Spur only; otherwise nil) > > 54 total size of free old space (Spur only, > otherwise nil) > > 55 ratio of growth and image size at or above > which a GC will be performed post scavenge > > 56 number of process switches since startup > (read-only) > > 57 number of ioProcessEvents calls since startup > (read-only) > > 58 number of ForceInterruptCheck calls since > startup (read-only) > > 59 number of check event calls since startup > (read-only) > > 60 number of stack page overflows since startup > (read-only) > > 61 number of stack page divorces since startup > (read-only) 62 compiled code compactions since startup > (read-only; Cog only; otherwise nil) > > 63 total milliseconds in compiled code > compactions since startup (read-only; Cog only; otherwise nil) > > 64 the number of methods that currently have > jitted machine-code > > 65 whether the VM supports a certain feature, > MULTIPLE_BYTECODE_SETS is bit 0, IMMTABILITY is bit 1 > > 66 the byte size of a stack page > > 67 the max allowed size of old space (Spur only; > nil otherwise; 0 implies no limit except that of the underlying > platform) > > 68 the average number of live stack pages when > scanned by GC (at scavenge/gc/become et al) > > 69 the maximum number of live stack pages when > scanned by GC (at scavenge/gc/become et al) > > 70 the vmProxyMajorVersion (the interpreterProxy > VM_MAJOR_VERSION) > > 71 the vmProxyMinorVersion (the interpreterProxy > VM_MINOR_VERSION)" > > > > > > Shaping > > > >

1 0

Re: [Vm-dev] [Pharo-dev] Squeak and Pharo speed differences
by Shaping 19 May '20

19 May '20

Another GUI-input speed observation: If you click the scroll wheel once to shift the text contents of the pane, the visual effect is very fast. I cannot detect any latency; it certainly is not close to what I see for text insertion/deletion, cursoring, and double-click selection. The slower operations all involve getting a damage rect at a specific point based on cursor position or click position. The faster scrolling function doesn’t need to do that. It just grabs the entire visible rectangle minus one line, and blits it shifted down by one line, along with the one new line. That looks like an almost zero-cost collection of damage rects. It’s a simple, fast calculation. Collection of damage rects for the slower operations looks much more expensive. The events involved in both cases are delivered to the target handler with the same latency. The slowness or quickness seems to have after that. Shaping Hence graphics output necessarily lags input on Morphic. So these speed differences have nothing to do with vm performance and everything to do with GUI architecture. Both Squeak and Pharo show the same delay for text selection latency. The architecture difference is not likely causing that. Given that both Pharo and Squeak useorphic and hence nothing have the same tender-in-step architecture isn’t the fact that they show the sane performance issue evidence that points to precisely this being the cause? Yes, but not architecture, by which I think you mean the pushing of events versus the fixed-frequency regular loop in Morphic. I would expect a big variation in the Morphic case, but I don’t know what the fixed frequency is; it could well under the noise floor. My first thought would be that getting the damage rects is the problem, but I’ve not seen the code. How do we index or look up the word rectangle to render? I’m think that is more likely the cause. Is a map created at method compile time and updated after text is moved during edits? My understanding is that damage rectangles are retrieved, Right, but this is the potentially slow part—the retrieving or perhaps more specifically mapping a point to a rectangle containing a contiguous sequence of non-whitespace character (a word). combined to produce a smaller (non-overlapping?) set, and that the entire morph tree is asked to render within these damage rectangles. You can read the gods for yourself. It’ll be a while. …. I just tried some new experiments. I should have thought of these earlier. Character insertion and cursoring in any direction by one character have the same latency. Collecting the damage rectangle at the cursor position and around the selected word are both taking about the same time as far as I can tell with my eye, and this time is longer than in VW or any Windows app. But VW doesn’t use the Windows message queue directly. All incoming Windows events are converted to Smalltalk equivalents and are queued on the Smalltalk side. And it works well. Why not mimic that pattern to get the extra speed? Does something in Squeak/Pharo architecture prevent us from doing that? How do we set a multi-process time profiler running so that we don’t need to eval blocks to get tallies. I just want to use the editor and watch method hit distribution. I see the Time profiler window; it seems to need a code snippet to work. How is the JIT code cache cleared? Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState. Okay. Can’t remember how it’s done in VW. CompiledMethod allInstancesWeakly do: [:compiledMethod | compiledMethod flushCachedVMCode] Baseline state: the only thing that comes to mind here is Collect All Garbage. There’s also Smalltalk garbageCollectMost which just runs a scavenge. IIRC someInstance has a side effect of running a scavenge in VW. Okay. and then ensure, through the relevant introspection primitives, What are these? What state features am I introspecting after the test? Sizes of heap subspaces? I can do Time microsecondsToRun: on the blocks. In Squeak/Pharo/Cuis see Smalltalk vmParameterAt: or Smalltalk vm parameterAt: and senders. Okay. I see this list: parameterAt: parameterIndex "parameterIndex is a positive integer corresponding to one of the VM's internal parameter/metric registers. Answer with the current value of that register. Fail if parameterIndex has no corresponding register. VM parameters are numbered as follows: 1 end (v3)/size(Spur) of old-space (0-based, read-only) 2 end (v3)/size(Spur) of young/new-space (read-only) 3 end (v3)/size(Spur) of heap (read-only) 4 nil (was allocationCount (read-only)) 5 nil (was allocations between GCs (read-write) 6 survivor count tenuring threshold (read-write) 7 full GCs since startup (read-only) 8 total milliseconds in full GCs since startup (read-only) 9 incremental GCs (SqueakV3) or scavenges (Spur) since startup (read-only) 10 total milliseconds in incremental GCs (SqueakV3) or scavenges (Spur) since startup (read-only) 11 tenures of surving objects since startup (read-only) 12-20 were specific to ikp's JITTER VM, now 12-19 are open for use 20 utc microseconds at VM start-up (actually at time initialization, which precedes image load). 21 root table size (read-only) 22 root table overflows since startup (read-only) 23 bytes of extra memory to reserve for VM buffers, plugins, etc (stored in image file header). 24 memory threshold above which shrinking object memory (rw) 25 memory headroom when growing object memory (rw) 26 interruptChecksEveryNms - force an ioProcessEvents every N milliseconds (rw) 27 number of times mark loop iterated for current IGC/FGC (read-only) includes ALL marking 28 number of times sweep loop iterated for current IGC/FGC (read-only) 29 number of times make forward loop iterated for current IGC/FGC (read-only) 30 number of times compact move loop iterated for current IGC/FGC (read-only) 31 number of grow memory requests (read-only) 32 number of shrink memory requests (read-only) 33 number of root table entries used for current IGC/FGC (read-only) 34 number of allocations done before current IGC/FGC (read-only) 35 number of survivor objects after current IGC/FGC (read-only) 36 millisecond clock when current IGC/FGC completed (read-only) 37 number of marked objects for Roots of the world, not including Root Table entries for current IGC/FGC (read-only) 38 milliseconds taken by current IGC (read-only) 39 Number of finalization signals for Weak Objects pending when current IGC/FGC completed (read-only) 40 BytesPerOop for this image 41 imageFormatVersion for the VM 42 number of stack pages in use 43 desired number of stack pages (stored in image file header, max 65535) 44 size of eden, in bytes 45 desired size of eden, in bytes (stored in image file header) 46 machine code zone size, in bytes (Cog only; otherwise nil) 47 desired machine code zone size (stored in image file header; Cog only; otherwise nil) 48 various header flags. See getCogVMFlags. 49 max size the image promises to grow the external semaphore table to (0 sets to default, which is 256 as of writing) 50-51 nil; reserved for VM parameters that persist in the image (such as eden above) 52 root table capacity 53 number of segments (Spur only; otherwise nil) 54 total size of free old space (Spur only, otherwise nil) 55 ratio of growth and image size at or above which a GC will be performed post scavenge 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck calls since startup (read-only) 59 number of check event calls since startup (read-only) 60 number of stack page overflows since startup (read-only) 61 number of stack page divorces since startup (read-only) 62 compiled code compactions since startup (read-only; Cog only; otherwise nil) 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil) 64 the number of methods that currently have jitted machine-code 65 whether the VM supports a certain feature, MULTIPLE_BYTECODE_SETS is bit 0, IMMTABILITY is bit 1 66 the byte size of a stack page 67 the max allowed size of old space (Spur only; nil otherwise; 0 implies no limit except that of the underlying platform) 68 the average number of live stack pages when scanned by GC (at scavenge/gc/become et al) 69 the maximum number of live stack pages when scanned by GC (at scavenge/gc/become et al) 70 the vmProxyMajorVersion (the interpreterProxy VM_MAJOR_VERSION) 71 the vmProxyMinorVersion (the interpreterProxy VM_MINOR_VERSION)" Shaping

1 0

Re: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Morph a few win32 files from CRLF/dos to LF/unix lineendings. [ci skip] (027e359)
by Eliot Miranda 19 May '20

19 May '20

Hi Jakob, thanks. I was unaware of either of these facilities. Feel free to make it so. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/027e3593d2c1082b7e…

1 0

Re: [Vm-dev] [Pharo-dev] Squeak and Pharo speed differences
by Shaping 18 May '20

18 May '20

== First, on the text selection delay issue. == Now that you mention it, the text seems to get highlighted slightly slower than in native Windows widgets or WordPad (which is what I had available for comparison). But it also behaves differently. Please try the following and report whether you experience the same delay: 1) click into the middle of a word with a single click - it won't get highlighted, Correct. 2) click again at the same cursor position How soon after? If more than a small fraction of second, this is just another single click. - the whole word should be selected now. No, not unless this is a double click. If I do a double click (splitting a double click into two different click locations is almost impossible), then the text highlights with a noticeable delay. Is the reaction to the second click also too slow? There is no response to the second click except to place the cursor in the same place again. A rapid sequence of clicks (double-click) must happen to cause selection. In regular Windows widgets you have to double-click, not click again, to toggle word selection. Your experienced delay might therefore be associated with Squeak/Pharo processing two consecutive single clicks and the OS widgets processing one proper double click event. But that's only speculation on my part, I didn't check the code. These are Pharo windows, not native Windows windows. I'm doing the tests in a Pharo 9 Playground. It follows the same selection protocol as a native window: a double click. Pharo has its own event loop, like VW, right? == Second, on the divergence of Pharo and Squeak == from my perspective and I have not been around at the time of the split yet. A general note: you will obviously get biased views from each side and the other one might view them as unfairly presented (which makes such discussions unproductive quickly). Moreover, much of the divergence is not in the VM but in the image, No good reason for image divergence has been given yet. The Pharo effort to modularize completely, if successful, gives all Squeak and Pharo Smalltalkers what they want: painless, reliable/predictable, deep fine-grain reconfigurability of the environ. Is there something else to want here? What does the bold stuff not cover? so you might not even be talking to the right people on the Squeak side. Since not everyone is subscribed to both (or all three) mailing lists, they might not see all the answers, so you cannot have a coherent discussion at all. I might not be mailing to the right lists. Feel free to make suggestions. To start with the example, I suppose the new preferences look has probably not gotten from Pharo into Squeak not because the Squeak community did not like it, but because it was simply not contributed back. The Squeak folks would have had to pull it and probably did not deem it important enough (or were not even aware if they don't use Pharo regularly). Yeah, that's a problem. Besides, the preferences in Squeak are also not a flat list, they have had categories for ages. The categories are in an alphabetic list. It should be a tree. The list is too long and doesn't show any organization besides the alphabetic ordering. That's the point. There is one invisible root and a wide first level-not much branching. Two levels. Also, the subitems in each category are sometimes alphabetic and other time not. I'd have to study the options for a week to determine what I would do differently, but I don't like the first impression this gives. There is some sense of subcategory, like several contiguous browse* items or syntax* items, but these groups should be in subnodes. I'm seeing three of four levels. I'm not sure. It would take some study. It doesn't feel coherent and compelling. It doesn't pull me in. It looks like a bunch of miscellaneous details. The Settings browser makes pretty get sense, yes? If the Squeak community was busy all the time pulling things --Not all the time, just what you can use when you need it. I don't think the need for tree is perceived beyond the two levels. back from Pharo, they could not concentrate on their own efforts. Can you tell me about those efforts? I know the VM is one, maybe the biggest. What else do Squeak folks work on? I also understand why the developers of the new Pharo preferences tree did not like to invest the same effort in Squeak. What incentive would they have? Make all features (GUIs/frameworks) loadable into a new, mostly empty image. Make all aware of those features. Knowing that this will happen for all feature-work contemplated will lower the threshold to doing the feature-work. A Squeak dev will learn about the Settings feature, for example, and adapt it if he wants. If we have the same basic graphical framework, there is nothing to adapt (to Morphic). It just works. Yes, the transition is painful. And there is always a new transition coming as new tech surfaces. We need a way to deal with that systematically without killing creativity and without creating so much disruption that commercial interests are wary of the environ. And here we are. Such differences and the additional effort are the liability of a fork, for both sides. Some people are or were active in both communities to invest the effort. For example, Eliot also provided the image side of VM improvements to Pharo, not only Squeak, if I remember correctly. I don't know whether he still does that since the fork of the VM. What fork of the VM? Please explain. Pharo would like to get rid of Morphic; as far as I know, Squeak embraces Morphic for its direct manipulation interface and UI discoverability (inspecting Morphs and such). Right. GTK has its inspector, but I don't know whether you get the same features out of it. Direct manipulation probably not, only indirect. And can you control that inspector from Pharo or do you have to write C code to change it in GTK itself? From my impression, this would be a no-go for Squeak. The tools must be maintainable in Smalltalk, working with C is a necessary evil in the VM. Maybe Pharo has found a way to have the best of both worlds, I don't know. I don't know much about GTK yet. I'll get to it. Still that leaves all Morphic applications behind; their UI (or even the entire program) would have to be rewritten from scratch. I doubt that Pharo will keep Morphic workable once they can drop it from the mainline. I don't understand. Drop? Why? If Morphic works and someone wants it, then keep it. Are you saying it would be dropped because it cannot be satisfactorily re-implemented with the GTK3 backend? What's wrong with keeping Morphic primitives? And Spec2 is not the first new idea of UI technology in Pharo, you know. In return, the different technology makes it harder for Squeak to port new features even if they wanted to, making it less likely to happen. Even some basic Collection API has changed in Pharo (string trimming and joining for example), now try to keep your code compatible with both without messing it up... Yes. The "port" is only difficult once if the aim is thereafter to work from a common base image. But there will be more ports and conversions. Is there a system on either side for managing incorporation of new tech, libraries, and standards? The compatibility and porting problems are offloaded to the application and library developers, even between Pharo releases. I don't know how this can be advertised as appealing to commercial development. VisualWorks & Co. could certainly not deal with their users that way. This happens in any case. That it happens in one image and not two is better. I don't think that Pharo does bad stuff in general, in fact their work could be very good (I don't look at it regularly and certainly don't follow the implementation). Like you said, disentangling, modularization, test automation, and innovation are valuable goals. Squeak mostly agrees on the goals, but does not pursue them in the same disruptive manner. Probably this is the "pushback" you have been told of... Right. How does squeak do things less disruptively? I agree that the innovation on the Pharo side is accompanied by almost as much bloat and confusion, especially for new comers trying to port. What is the Squeak way of improving the frameworks and using new tech, like 3rd part libs? If Spec is a UI generalization framework that makes it independent from the graphics implementation, Yes, that's the aim. then one should rather compare it to Squeak's ToolBuilder, not Morphic. ToolBuilder as well could have different targets, such as GTK, (I have seen Squeak tools rendered with some Java UI Framework a few months ago) but nobody pushes that in the Squeak trunk. There was no voiced demand. I don't know ToolBuilder. Perhaps I should have a look. Why would the best of both TB and Spec2 not be used in a common base tool-building framework, which sounds broader than what Spec2 does, but may not be? I don't know enough of TB to say. How is framework adoption/inclusion decided? The dev who writes the framework first and demonstrates utility first with that framework will have it included in the base image? Just thinking aloud. How does it work? How do you want it to work? I haven't participated in such discussions of the right wayT in the past, but my impression from what I heard so far is that Pharo pushes forward rigorously and does not look back, and if it does, then sometimes with a disparaging or snappy tone. Does this mean that Pharo folks are unfairly critical of old frameworks in order to push the new thing (whatever it is) along? Some of the Squeak guys are therefore very sceptical about Pharo and their attitude, to say the least, and sometimes also talk harshly. I can see how that might happen. Too many changes too quickly doesn't look like innovation to some. It looks risky, especially to commercial interests, but clearly the consortium don't want this view. It's not healthy for Pharo or Smalltalk. The recent fork of the VM further deepens the trenches, Okay, this must have been the fork I saw Eliot mention a few weeks back. I don't know the details, but it sounds like a bad idea. especially since the foundation of "OpenSmalltalk" VM (no longer "Squeak" VM) was in my perception a commitment to cooperate at least on that end. There are probably only a bunch of persons who are responsible for the bad mood, and I assume that the majority of both communities are in fact friendly people. :-) So it seems, but I don't know the details. I prefer to focus on the tech, not personalities and self-esteem issues. Thanks for the perspective. Shaping Am Sa., 16. Mai 2020 um 08:40 Uhr schrieb Shaping < <mailto:shaping@uurda.org> shaping(a)uurda.org>: > > > > Why can't the OSVM be a single, unforked, maxed-out VM with all the best and fastest features working in Squeak and Pharo? Why did the split happen? > > > > In very general terms, the fork was due to their being Group A wanting > to go one direction and Group B wanting to go in a different direction. i.e.... > > B says "We want to do X". > > A says "We don't want to do X." > > B says "We really want to do X." > > A says "Definitely no." > > B says "We really want to do X and actually we're doing it over here." > > > > Lol Thanks for the explanation. That's more or less what I thought. > > > > But can't the differences be setup at config-your-environ time instead of build time, when the task is heavier and slower? > > > > In essence, Squeak considered backward compatibility of prime importance including the code of some applications that had become entangled in the main code base. Pharo wanted to "clean the code" by disentangling and stripping those parts. > > > > I like disentangling and modularizing. I suppose this is a universal like. > > > > They also wanted to move to a reproducible-build-system where each > change "bootstrapped" a nightly image from an empty file, > > > > I like this too. > > > > whereas Squeak continues to use a "continuous evolution" model. > > > > Don't both groups want the automatic building and testing the Consortium is talking about recently? > > > > I'm not sure I understand how "continuous evolution" works. Sounds like there is lots of wiggle room in that idea. Don't we need some structure? We seem to be getting that in Pharo. > > > > I'm not sure about Squeak. The GUI tools/menus still feel hodgepodge (much nicer, but still not well organized) 16 years later. I used it between 2002 to 2004, and then again just a few days ago. I like the faster debugger and the flat GUIs, but I don't need Morphic to have those dev-tool GUIs. I'd prefer to rework the GUIs with Spec2/GTK3, and keep the flat, clean, button-packed look with some improvements (like the new Spec2 selection highlighting pattern, which is very nice). The rest of Squeak seems messy. > > > > I do very much like the technical, concrete feel of Squeak's details about the VM. That reminds me of old times and why I got involved in computers, and it supports my current interest in VM parallelization. Those VM details need a somewhat different shape/presentation. There is a beauty in Squeak, but the eviron still feels a bit rough. > > > > For example, why aren't all those preferences in a tree where you can actually find things because they are categorized. It's a big list. That seems very strange in 2020. Why don't Squeak folks borrow the Pharo Settings GUI idea, and implement that in Morphic, as they like? I thought more would have happened in the Squeak GUI in 16 years, but I've not seen all of 5.3 yet. I'm still poking around. I suppose most of the improvements are in the VM, which I imagine absorbs most of the group's energy. > > > > And there are more reasons I probably not aware of. > > Here is the Pharo Vision document circa 2012 which inspired me > <https://hal.inria.fr/hal-01879346/document> https://hal.inria.fr/hal-01879346/document > > > > Thank you. I will read it. Is the Consortium updating that doc? There was a doc recently from Stef that looks like it belongs in there, merged somehow. > > > > It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently. > > > > Trying to go one way and dealing with continual pushback and conflict around that is also bad energy. > > > > Agreed. I don't understand the pushback because I don't understand Squeak folks' objection to rigorous, systematic, automatic testing and disentangling/modularizing of frameworks. They are probably fine with all that. Do Squeak folks have a document that defines "continuous development." I know that VM testing is automated. I don't see how the objectives are so different, at least on the automation front. Everyone seems to agree that CI is good. > > > > > > I want to help, but need to port first from VW, and I'm trying to choose Squeak or Pharo. Both have speed problems. Squeak has fewer, but Pharo could be much faster with broad use of Spec2. > > > > Would reintegrating Squeak and Pharo development make more sense? > > > > I think that is not likely. Both continue to have different goals. And a significant area where they are likely to continue to diverge is the graphics. Squeak is likely(?) to stay with Morphic a long while Pharo intends to dump Morphic. > > > > I never liked the halo thing. It's okay. It seemed/seems too busy and distracting. I think Morphic and the "too many cooks" problem is why I broke off in 2004. > > > > If we are fully modular, and you love Morphic, and want to live there mentally and visually, all the time, then load the Morphic package into the new universal OpenSmalltalk. Have all your GUIs built with Morphic. Have cute little morphs stuck here and there. Knock yourself out. Don't like Morphic? Don't think it's cute? Load the more business-like-but-not-boring Spec2. I don't see an insurmountable technical problem here. > > > > > > This is one of the reasons that Spec was created - to be independence layer. > IIUC in Pharo 9 Spec is already working on top of a GTK3 backend. > > > > Yes, the Spec2 Launcher is inspiringly snappy, modulo the text-selection slowness problem, which is everywhere in Pharo and Squeak. I've mentioned this a few times recently-of all the goofy things to prevent a port from VW...Okay, that and Pharo's slow debugger. Two things keep me out of Pharo/Squeak. I don't love VW. I tolerate it really well. That's different. J > > > > wrt the VM, Pharo want to remove all native-windowing from the VM, so > that window opening > > is controlled from the Image via FFI rather than the VM. > > > > I agree with the objective. > > > > This conflicts with Squeak's backward comparability goals. > > > > Okay, this is the real problem. > > > > So there is a ton of old Squeak code that no one is willing to rework in order to be compatible with the new vision for native-windowing independence. Perhaps someone can give more details on that old code. > > I suppose many Squeak folks bemoan all the extra work needed for a recoding. Is this still really an issue? Maybe very little of that old code is still being used in business-critical ways. The need for a recoding may not be the big issue it once was. > > > > This change would effectively create more devs willing to work on any problem. This change would also prevent fracturing of feature-sets across the two Smalltalks from happening in the first place. > > > > I personally had the inspiration that Squeak might be based off the > Pharo Headless Bootstrap, > > but in the end I didn't find the time to push this further. > > > > That's a very good idea. Why don't all the Squeak folks work on it? Are you the only one pushing for this? > > > > > > Squeak and Pharo GUI styles are different. So be it. Can't the GUI frameworks and conventions be separated in the same image, and configured as desired in GUI sections of Settings? > > > > Pharo currently can use both Morphic and GTK3 for its GUI backend. > Possibly the GTK3 backend would provide some speed benefit (??) > > > > It's a good question. Is the core Morphic issue whether GTK3 can render non-rectangular shapes efficiently? There's a lot of that in Morphic. I suppose it's the main concern. Even if Morphic relies on special drawing primitives, they can go in a lib and be accessed via FFI. > > > > Shaping

8 15

Red Alarm!
by Janko Korelc 17 May '20

17 May '20

Red Alarm! 2 days ago had found databaseCriticsBrowser.zip and installed several packages from the catalog. NeuralNetworks installed successfully for the first time. Several image saves later, was dissatisfied with something, and as noticed option to revert changes, tried it. Look, everything got uninstalled! WTF? Thought, then at least let's install NN again. Only to discover I can not. Today, I believe it got deleted for a strange reason. Try to recover and those dangerous variants shall be removed from the public. For the curious look in group Compiler at my comment in topic: What should we do with programmers who introduce errors in code. -- gee, gravitino, graviton exchange

1 0

Re: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Morph a few win32 files from CRLF/dos to LF/unix lineendings. [ci skip] (027e359)
by Jakob Reschke 17 May '20

17 May '20

If a particular kind of line endings is needed, this should also be in .gitattributes (`*.c text eol=lf` and the same for *.h) and maybe .editorconfig. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/027e3593d2c1082b7e…

1 0

Build completed: opensmalltalk-vm 1.0.2077
by AppVeyor 17 May '20

17 May '20

1 0

Build failed: opensmalltalk-vm 1.0.2076
by AppVeyor 17 May '20

17 May '20

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2020