October 2020 - Pharo-dev - lists.pharo.org

This week (44/2020) on the Issue Tracker

by Marcus Denker

NewTools and Spec merge ==================== https://github.com/pharo-project/pharo/pull/7510 v0.4.5 - StInspector and StDebugegr now uses a paginator to better show miller collumns. - Some minor bugfixes - Activated CI NewTools v0.4.4 - new tool SystemReporter (thanks Stef) - some changes on debugger inspector ui, looking to make things more pleasant. - fixes pharo-spec/NewTools#120 - fixes pharo-spec/NewTools#113 - fixes #6940 - fixes #7456 - fixes #7453 - fixes #7451 Spec2 v0.7.5 - SpFilterWithListPresenter was renamed to SpFilteringListPresenter. - lists and trees now use displayIcon: to answer an icon instead icons:. - new presenters SpPaginatorPresenter and SpMillerPaginatorPresenter. - Add decoration attributes to SpStringTableColumn - several fixes to SpMillerColumnPresenter. - fixes pharo-spec/Spec#952 - fixes pharo-spec/Spec#940 - fixes pharo-spec/Spec#954 - fixes pharo-spec/Spec#929 - fixes pharo-spec/Spec#871 - ... and several other bugfixes Breakpoints =========== Some fixes related to styling. Merge-MetaLinkStyler #7596 https://github.com/pharo-project/pharo/pull/7596 535-Variable-Breakpoints-Wrong-Icon-in-gutter #7551 https://github.com/pharo-project/pharo/pull/7551 First Class Variables ===================== 6001-isTemp-might-fail-on-Pharo-AST #7586 This PR intruduces UnresolvedVariable. When the AST is created by the parser, it sets all Variables to this kind. This allows us to - get a meaningful answer to all is*Variable checks: false (as it is not eg. a temp yet) - visitor works correctly and falls back to #visitVariable node no need for any ifs - nice errror messages if you try to generate code https://github.com/pharo-project/pharo/pull/7586 Read-Only Literals ================== isReadOnlyLiteral-Float-Integer #7553 Float and Integers are now read-only if they are referened from the code and not immediate https://github.com/pharo-project/pharo/pull/7553 7592-add-beRecursivelyReadOnlyObject #7593 We have beReadOnlyObject, but often it makes sense to set an Object recursively read-only. One example we see with literal arrays: right now we just make the outer array read-only, but we should recurse into it and make all the content read-only, too. Based on the RecursiveWriteBarrier package by khinsen, with small improvements: - after we merged #7590 , we do not need the exception handler anymore - instead of using instVarNamed:, we should use #instanceVariables and then the reflective read/write API of the first class variable objects https://github.com/pharo-project/pharo/pull/7593 7589-isReadOnlyObject-and-beReadOnlyObject-are-not-consistent-wrt-immediate-objects #7590 1 isReadOnlyObject returns true, but calling #beReadOnlyObject raises an error. #isReadOnlyObject has an explicit check for this case in the fallback code, we should add the same to #beReadOnlyObject. https://github.com/pharo-project/pharo/pull/7590 7591-We-have-isImmediateClass-add-isImmediateObject #7594 https://github.com/pharo-project/pharo/pull/7594 Variables-use-pushLiteral #7597 For both MetaLinks and Slots we added code in the past to not use pushLiteral: directly. The idea was that this would be needed for read-only litereals. But the implementation of read-only literals is now that only literals are compiled read-only, we can use the literal frame to e.g. reference Variables or MetaLinks without any problem. https://github.com/pharo-project/pharo/pull/7597 Fluid Class Definition ======================= ChangeGreaterThanIntoGreaterGreaterForFluidClass #7606 https://github.com/pharo-project/pharo/pull/7606 7602-preparing-fluid-syntax-changes #7603 https://github.com/pharo-project/pharo/pull/7603 7598-SpPresenter-class-does-not-display-instanceVariableNames- #7601 https://github.com/pharo-project/pharo/pull/7601 Small cleanups in FluidClassBuilder package #7577 https://github.com/pharo-project/pharo/pull/7577 Cleanup FluidClassBuilder-Tests package #7579 https://github.com/pharo-project/pharo/pull/7579 Graphics ========= Add support for mesh gradients to Athens #7546 https://github.com/pharo-project/pharo/pull/7546 Fix crashes and memory leaks in OSSDL2AthensRenderer #7543 https://github.com/pharo-project/pharo/pull/7543 Fixes ===== DNU in RubCurrentLineBarDecorator for #compose #7552 https://github.com/pharo-project/pharo/pull/7552 7582-New-Release-of-Microdown--v105 #7583 https://github.com/pharo-project/pharo/pull/7583 isClean-using-CleanBlockChecker #7540 #isClean was implemented using abstractBytecodeMessagesDo: which is slow due to trapping MessageNotUnderstood and creating messages for every bytecode. This PR adds a dedicated CleanBlockChecker that checks for the bytecodes and stops scanning as soon as it determines a block to not be clean. In addition, we move the testIsClean from OCClosureTest to BlockClosureTest and remove the example code from #isClean (the test now has that). https://github.com/pharo-project/pharo/pull/7540 Cleanup for Fonts ================== FontProviderAbstract should be renamed to AbstractFontProvider #7609 https://github.com/pharo-project/pharo/pull/7609 FontFamilyMemberAbstract should be renamed to AbstractFontFamilyMember #7611 https://github.com/pharo-project/pharo/pull/7611 FontFamilyAbstract should be renamed to AbstractFontFamily #7605 https://github.com/pharo-project/pharo/pull/7605 Cleanup FreeTypeCache #7561 https://github.com/pharo-project/pharo/pull/7561 Cleanup FreeTypeCacheLinkedList #7565 https://github.com/pharo-project/pharo/pull/7565 Remove unnecessary comment in FreeTypeCacheConstants #7563 https://github.com/pharo-project/pharo/pull/7563 Small cleanup in FontFamilyAbstract #7567 https://github.com/pharo-project/pharo/pull/7567 Cleanup FreeTypeGlyphRenderer #7559 https://github.com/pharo-project/pharo/pull/7559 Cleanup FreeTypeSubPixelAntiAliasedGlyphRenderer #7557 https://github.com/pharo-project/pharo/pull/7557 Small cleanup in FreeTypeFontProvider #7548 https://github.com/pharo-project/pharo/pull/7548 Cleanup Fonts-Abstract package #7555 https://github.com/pharo-project/pharo/pull/7555 Misc Small Cleanups ============= Cleanup ExternalType>>#cleanupUnusedTypes #7569 https://github.com/pharo-project/pharo/pull/7569 Simplify Form>>#bitsSize #7571 https://github.com/pharo-project/pharo/pull/7571 Cleanup Flashback-Decompiler-Tests package #7581 https://github.com/pharo-project/pharo/pull/7581 Simplify Socket>>#dataAvailable #7573 https://github.com/pharo-project/pharo/pull/7573 Use ifNil: in BitBlt>>#fillColor: #7575 https://github.com/pharo-project/pharo/pull/7575 Move SystemAnnouncement extensions from Calypso #7538 Calypso introduced nice methods for SystemAnnouncement like affectsMethod: , affectsClass:. They can be reused by other tools to analyze system changes. And therefore they should be packaged together with Announcement classes. https://github.com/pharo-project/pharo/pull/7538

Oct. 30, 2020

[ANN] Next Pharo Sprint: Oct 30

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Oct 30 (this Friday) Goals of this sprint: - Fix issues from tracker https://github.com/pharo-project/pharo/issues This is a Remote Sprint, it happens on Discord. http://pharo.org/contribute-events We have added a Board to coordinate the work: https://github.com/orgs/pharo-project/projects/9 A list of all Pharo Event of the year an be found here: https://association.pharo.org/events

Oct. 27, 2020

This week (43/2020) on the Issue Tracker

by Marcus Denker

This week (43/2020) on the Issue Tracker ========================================= Roassal (Visualisations) and Graphics: -------------------------------- - Load the new version of Roassal, which is 0.9.5 https://github.com/pharo-project/pharo/pull/7461 - Do not disable freetype text hinting in Cairo #7544 https://github.com/pharo-project/pharo/pull/7544 - 7529-ImageReadWriter-should-raise-a-specialised-exception-and-not-Error #7530 https://github.com/pharo-project/pharo/pull/7530 First Class Variables ---------------------- We have now meta-objects that describe any Variable defined, be it a Global, Class Var, instance Var, temp, and others. We are continuing to refine the model and start to see where it can be used to generalise and simply. - Improve DoIt DoIts were loosing the requestor scope on the level of the AST. With that now fixed, we will be able to access variables declared by the Playground from the debugger (and highlight them correctly) These needs multiple steps to be enabled, here are two: Doit-RequestorScope #7511 https://github.com/pharo-project/pharo/pull/7511 DoIt-access-with-ReadVariable #7512 We now read temps from the context with a general "read Variable named" method, this way it will be able to read and write WorkspaceVariable instances, too: https://github.com/pharo-project/pharo/pull/7512 - The new bytecodeset has a bytecode for "push the current process". This should be exposed by the backend. To be done: show how to implement "ThisProcessVariable". CompilerBackend-pushThisProcess #7513 https://github.com/pharo-project/pharo/pull/7513 - Cleanup-referredInstVars #7541 If you look at referredInstVars, it return names of indexed instance variables. No users, no test. With First Class Variables, we can do better as soon as we need it. (we should now operate in terms of Variable *objects* not names!) https://github.com/pharo-project/pharo/pull/7541 - Variables-isTempVariable #7524 The last of the is* renamings. To be consistent with all the other is*Variable, we rename isTemp to isTempVariable (with deprecation) https://github.com/pharo-project/pharo/pull/7524 - Introduce ForeignVariable to model a unified access to variables #7527 This gives a nice perspective on what will be possible with First Class Variables: Introduce special ForeignVariable to model a unified access to variables from any context. For example it will allow us to transparently use temps from the local context in doIt expressions. (This will avoid the rewrite to ThisContext tempNamed: to access variables in a DoitIn:) https://github.com/pharo-project/pharo/pull/7527 Breakpoints =========== The improvements for Breakpoints are, too, driven by First Class Variables. e.g. Class Variables being Objects and easy to query, we can implement VariableBreakpoint for Class Variables very easily: 7421-Variable-breakpoints-do-not-work-on-class-variables #7531 https://github.com/pharo-project/pharo/pull/7531 Variables will open *many* opportunities for cleanups here... e.g. we can unify all Variable Breakpoint code to just operate on Variables. No nedd to check "if this is the name of a temp, do that, if that of an ivar, that other thing". As a first step, we did: MetaLinkResolver-simplify #7528 Use the reflective API directly to discover Variables https://github.com/pharo-project/pharo/pull/7528 VariableBreakPoint-package-merge #7542 https://github.com/pharo-project/pharo/pull/7542 Compiler ======== ScaledDecimal-readOnlyLiteral #7534 Another step for compiling literals read-only that are referred to in the source. We are just missing Boxed Floats and large Integers after this: https://github.com/pharo-project/pharo/pull/7534 CaseOf-Remove-BackendError #7517 The Design of the Opal Compiler, it was made as compatible to the old as possible. Including raising an error where it is better to fall back to just emit non-optimized code for #caseOf: https://github.com/pharo-project/pharo/pull/7517 Cleanup-headerFlagForEncoder #7518 Small cleanup of code that was just there to support the old Compiler https://github.com/pharo-project/pharo/pull/7518 Fluid Class Builder --------------- Work continuous for the Fluid Class definitions: 7515-Fix-dependencies-introduced-by-tests-of-FluidClassBuilder #7516 https://github.com/pharo-project/pharo/pull/7516 7490-definition-on-classDescription-can-be-simplified #7491 https://github.com/pharo-project/pharo/pull/7491 Cleanups/Small Fixes / Comments -------------------- And as always, we did some smaller cleanups and improvements: Add backwards compatibility Pharo9 to Pharo8 #7502 https://github.com/pharo-project/pharo/pull/7502 Fix #7507: Methods comments in Collection #7509 https://github.com/pharo-project/pharo/pull/7509 Replace Character cr asString to String cr #7526 https://github.com/pharo-project/pharo/pull/7526 Introduce symbolic platform independent name to the morphic keyDown and keyUp events #7508 https://github.com/pharo-project/pharo/pull/7508

Oct. 23, 2020

This week (42/2020) on the Issue Tracker

by Marcus Denker

This week (42/2020) on the Issue Tracker ================================ Debugger ======= Mostly improvements for Breakpoints this week. - Revert "Debugger-should-show-Workspace-bindings" #7452 https://github.com/pharo-project/pharo/pull/7452 - 7413-remove-breakpoint-does-not-remove-breakpoint #7496 https://github.com/pharo-project/pharo/pull/7496 - 7423-Breakpoint-on-while-nodes-do-not-work https://github.com/pharo-project/pharo/pull/7492 Spec ---- merge Spec2 0.7.4 #7493 https://github.com/pharo-project/pharo/pull/7493 - Organise and comment properly ALL widget presenters (children of SpAbstractWidgetPresenter) that are needed to create SpPresenter compositions. - Add missing examples for all widget presenters. - Presenter comments are now implemented through a microdown template, showing interesting sections and pointing to correct API to use (along with examples). - SpAbstractWidgetPresenter hierarchy now understands selectFirst. - New presenter SpTreePresenter. A tree with just one column. - SpTreeTablePresenter now understands expandPath: and expandRoots. - Added SpLinkTableColumn to add links to tables (and trees). - New utility presenter: SpListWithFilterPresenter. - Fixed alignment of cells on SpGridLayout. - SpGridLayout axis constraints now understand alignment (because sometimes you want to align a whole column, not just a cell). - Several fixes on commands for Pharo interaction. - Lots of small bugfixes. - See: https://github.com/pharo-spec/Spec/releases/tag/v0.7.4 Fluid Class Definitions -------------- This is ongoing work to have a better class definiton for what is now called "slot enabeled class defintion" (the one where one can use First Class Variables and where the Layout class is shown explicitly) 7458-Fluid-Class-integration-part-5 #7464 https://github.com/pharo-project/pharo/pull/7464 7465-Fluid-class-integration-part-6 #7466 https://github.com/pharo-project/pharo/pull/7466 7467-Fluid-class-definition-activation #7469 https://github.com/pharo-project/pharo/pull/7469 7470 fluid class a class definition can be expanded #7476 https://github.com/pharo-project/pharo/pull/7476 7472-Fluid-Class-refactor-classParser-hierarchy #7479 https://github.com/pharo-project/pharo/pull/7479 7481-testSharedSlotNodeArePolymorphicToRBVariableNodes-is-failing-in-default-image #7484 https://github.com/pharo-project/pharo/pull/7484 7473-Fluid-Class-clean-definitionWithSlotsdefinitionWithoutSlot #7485 https://github.com/pharo-project/pharo/pull/7485 Bug Fixes --------- 7500-Remove-argument-refactoring-from-Calypso-hangs-forever https://github.com/pharo-project/pharo/pull/7501 Playground-Self-Bindings #7419 https://github.com/pharo-project/pharo/pull/7419 Fix #6448 Add a way to get a FileLocator when possible instead of a FileReference #6449 https://github.com/pharo-project/pharo/pull/6449 7443-Compiling-a-method-with-a-non-declared-temps-raises-a-DNU #7450 https://github.com/pharo-project/pharo/pull/7450 Comments / Documentation ------------- Fix #7462: Enhance the help of how to use Travis #7463 https://github.com/pharo-project/pharo/pull/7463 improvement of the travis help #7506 https://github.com/pharo-project/pharo/pull/7506 CI failing tests ----------------- Skip-HiExamplesTest-testAllExamples #7442 https://github.com/pharo-project/pharo/pull/7442 Better way to design HiExamplesTest #7480 https://github.com/pharo-project/pharo/pull/7480 Cleanups -------- Cleanup-NautilusRefactoring-Shortcuts #7494 https://github.com/pharo-project/pharo/pull/7494

Oct. 15, 2020

Re: beta testers for the new version of the Pharo mooc

by Christopher Fuhrman

Hi Stef, I began some beta testing and noticed the Pharo Version of the image for the Mooc is blank (as opposed to 80, like the other images) on my Windows 10 WSL2 (Ubuntu) version of Pharo Launcher 2.2 (although when I open the mooc image, it says it is 8.0.0). [image: image.png] The image runs fine, but it might be confusing to newbies. Cheers, Cris On Wed, 30 Sep 2020 at 10:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hello guys > > We are looking for beta tester for the new version of the Pharo mooc. > The beta test period is planned from 12 to 23 of october > Let me know if you can help. > > Tx > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Oct. 15, 2020

Re: [Pharo-users] Re: [ANN] Libgit 1.0.0 in Pharo 9

by Martin McClure

Yeah, apparently since libgit2 v0.99. Previously there was some other regex code built-in. But, as I replied to Pablo, you can build PCRE into the newer versions to avoid the runtime dependency. Regards, -Martin On 10/13/20 1:36 AM, ducasse wrote: > Libgit depends on PCRE. O_o > >> On 13 Oct 2020, at 10:20, tesonep(a)gmail.com wrote: >> >> Hi Martin, >> thanks for testing it. Can you tell me the version / flavour of >> Debian are you using? >> Maybe we need to ship PCRE with the VM. I am not fun of that, but we >> need to do it until we can have a proper packaging for each Linux >> distribution (Esteban is working on having a nice OBS configuration >> for the VM extending what Holger has previously done). >> It takes time and a lot of testing, but the idea is to fix (or at >> least control better) the dependency nightmare between different Linux >> distributions. >> >> Cheers, >> Pablo >> >> On Tue, Oct 13, 2020 at 7:49 AM Martin McClure >> <martin(a)hand2mouse.com> wrote: >>> Thanks, this is great news. >>> >>> Are there instructions on how to make P9 actually use the new version of >>> libgit2? I see that the stable Linux VM for 9.0 does include >>> "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1. >>> >>> ...this may be because Pharo's libgit2.1.0.0.so has not-found >>> dependencies on libpcre.so.3 and libpcreposix.so.3. >>> >>> I find Debian's versioning of libpcre somewhat confusing. The package >>> "libpcre3" is the *old* libraries, and new stuff is supposed to use >>> "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming >>> is rather distro-specific, and although I have the right packages >>> installed, the libraries have different filenames. >>> >>> But libgit2 is not supposed to have PCRE as a dependency. The source >>> code for PCRE is included in the source for libgit2. Seems like it would >>> be possible (and nice!) to compile the libgit2.1.0.0.so included with >>> the VM to include the PCRE code internally, rather than depend on an >>> external library. >>> >>> Thanks, >>> -Martin >>> >>> On 10/12/20 2:26 AM, tesonep(a)gmail.com wrote: >>>> Hi, a later announcement (this have been done some months ago... but I >>>> never send the mail). >>>> >>>> We have upgraded in Pharo 9 to use the latest stable version of Libgit. >>>> It required to have some improvements in Libgit to handle the updated >>>> version and also to support the previous version. >>>> >>>> From the point of view of new features, it does not add new things. >>>> However, this version fixes a lot of existing problems in Libgit. >>>> >>>> We can be sure this was a successful deployment as we don't have >>>> problems with it. We are really happy that this has been done >>>> transparently and keeping the working version with different >>>> configurations of images and VMs. As we should support new and old >>>> images, on the same VM. And also running new images in old VMs >>>> >>>> Thanks. >>>> >> >> -- >> Pablo Tesone. >> tesonep(a)gmail.com > >

Oct. 14, 2020

Re: [ANN] Libgit 1.0.0 in Pharo 9

by Martin McClure

Hi Pablo, I run Gentoo stable on my main systems (though Ubuntu on others). I ran an experiment this morning. By default, when you build libgit2, it uses the system's PCRE library if there is one. However, if you build libgit2 with cmake -DREGEX_BACKEND=builtin ../libgit2-1.0.0 cmake --build . Then it builds libgit2 with PCRE support built-in from libgit2's own copy of the PCRE sources, and gets rid of the external dependency. Pharo seems to like the resulting library just fine. Shipping libgit2.so with PCRE built-in seems like the cleanest short-term solution. I also noticed that in the stable 9.0 VM from June (which I believe is the latest stable VM?) the libgit2 v1.0.0 library has the wrong name and so P9 always loads the 0.25.1 version. The shipped name: libgit2.1.0.0.so should be libgit2.so.1.0.0 Thanks, -Martin On 10/13/20 1:20 AM, tesonep(a)gmail.com wrote: > Hi Martin, > thanks for testing it. Can you tell me the version / flavour of > Debian are you using? > Maybe we need to ship PCRE with the VM. I am not fun of that, but we > need to do it until we can have a proper packaging for each Linux > distribution (Esteban is working on having a nice OBS configuration > for the VM extending what Holger has previously done). > It takes time and a lot of testing, but the idea is to fix (or at > least control better) the dependency nightmare between different Linux > distributions. > > Cheers, > Pablo > > On Tue, Oct 13, 2020 at 7:49 AM Martin McClure <martin(a)hand2mouse.com> wrote: >> Thanks, this is great news. >> >> Are there instructions on how to make P9 actually use the new version of >> libgit2? I see that the stable Linux VM for 9.0 does include >> "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1. >> >> ...this may be because Pharo's libgit2.1.0.0.so has not-found >> dependencies on libpcre.so.3 and libpcreposix.so.3. >> >> I find Debian's versioning of libpcre somewhat confusing. The package >> "libpcre3" is the *old* libraries, and new stuff is supposed to use >> "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming >> is rather distro-specific, and although I have the right packages >> installed, the libraries have different filenames. >> >> But libgit2 is not supposed to have PCRE as a dependency. The source >> code for PCRE is included in the source for libgit2. Seems like it would >> be possible (and nice!) to compile the libgit2.1.0.0.so included with >> the VM to include the PCRE code internally, rather than depend on an >> external library. >> >> Thanks, >> -Martin >> >> On 10/12/20 2:26 AM, tesonep(a)gmail.com wrote: >>> Hi, a later announcement (this have been done some months ago... but I >>> never send the mail). >>> >>> We have upgraded in Pharo 9 to use the latest stable version of Libgit. >>> It required to have some improvements in Libgit to handle the updated >>> version and also to support the previous version. >>> >>> From the point of view of new features, it does not add new things. >>> However, this version fixes a lot of existing problems in Libgit. >>> >>> We can be sure this was a successful deployment as we don't have >>> problems with it. We are really happy that this has been done >>> transparently and keeping the working version with different >>> configurations of images and VMs. As we should support new and old >>> images, on the same VM. And also running new images in old VMs >>> >>> Thanks. >>> > > -- > Pablo Tesone. > tesonep(a)gmail.com

Oct. 13, 2020

Re: P3Converter and DateAndTime>>#readFrom: performance

by Sven Van Caekenberghe

Hi Estaban, I took some time to properly look at your remarks/suggestions. You are right, the chronology conversions could be improved and made faster. I committed the following https://github.com/svenvc/P3/commit/dd06eb33d0147060e0b6f44c704e2e298f55c0d4 "As noted/analysed by Esteban A. Maringolo, incoming conversions for Timestamp/DateAndTime and Date especially were slow. He suggested to take advantage of the known ISO format. Introduction of P3ISO8601Parser that implements a fast, non-checking parser specifically for the PSQL 8601 format. Use P3ISO8601Parser for the chronology conversions in P3Converter, for a 5x to 10x speedup. Note that for this to work, the connection output format must be ISO, the default." I did the following small test to confirm the improvements: p3client := P3Client url: 'psql://sven@localhost:5432/'. p3client execute: 'DROP TABLE IF EXISTS table1'. p3client execute: 'CREATE TABLE table1 (id SERIAL PRIMARY KEY, name TEXT, t1 TIMESTAMP WITHOUT TIME ZONE DEFAULT CURRENT_TIMESTAMP, t2 TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, t0 TIME DEFAULT CURRENT_TIME, d1 DATE DEFAULT CURRENT_DATE)'. 1 to: 100 do: [ :each | p3client execute: 'INSERT INTO table1 (name) VALUES (''n-' , (each + 999 atRandom) asString , ''')' ]. [ p3client query: 'SELECT * FROM table1' ] bench. p3client close. This query (6 columns, 100 rows) went from 68.332 per second to 446.711 per second on my machine. Thanks again for your feedback, it was most useful. Do these changes work for you ? Regards, Sven > On 12 Oct 2020, at 15:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Esteban, > > Thanks for this detailed feedback, this is most interesting. > > I don't have enough time to look at this in detail, I will do so later, but here is some initial feedback. > > Note that PostreSQL supports many different date/time formats and that the user can set preferences per connection, hence some flexibility in parsing is probably needed, and that is one reason why the parsing is implemented the way it is. > > Check section 8.5.2. from https://www.postgresql.org/docs/13/datatype-datetime.html > > Note that all of the following give the same result: > > Date readFrom: 'March 2 2020' readStream. > Date readFrom: '3/2/2020' readStream. > Date readFrom: '2020-03-02' readStream. > > Date parsing is probably slow because it has to deal with all these formats. > > Of course, parsing a fixed well-known format is always faster. > > The timezones are tricky too, as preferences can be set per connection, so we have to be careful. > > I will come back to this. > > Sven > >> On 12 Oct 2020, at 15:04, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> Hi, >> >> I recently stumbled into some performance issue I had, so I profiled >> it and got it fixed, but by doing that I also noticed a huge time >> spent when reading DateAndTimes and Dates (which also uses the former) >> and the culprit seems to be `Date class>>#readFrom:`. >> >> Digging into this, I noticed that this was called from >> `DateAndTime>>#readFrom:`, but in particular 90% of the time spent was >> when instantiating the Date part of it, because it does unnecessary >> lookup of the index of Month when input stream only have a month >> index. >> >> What I did then was to change the default behavior of DateAndTime >> class>>#readFrom: >> >> readFrom: aStream defaultOffset: defaultOffset >> "Parse and return a new DateAndTime instance from stream, >> as a Date, an optional Time and an optional TimeZone offset. >> The time defaults to midnight, the timezone to defaultOffset" >> "self readFrom: '2013-03-04T23:47:52.876+01:00' readStream" >> >> "From this" >> date := Date readFrom: aStream. >> >> "To this" >> date := Date readFrom: (aStream next: 10) pattern: 'yyyy-mm-dd'. >> >> And also in P3Converter to specify the pattern directly. >> >> P3Converter>>#convertDateFrom: bytes length: length description: description >> ^Date readFrom: (self asciiStreamFor: bytes length: length) pattern: >> 'yyyy-mm-dd' >> >> With these two changes I got a 8x-10x speedup when reading >> Date/DateAndTime from the database. >> >> Then I dig a little further and in P3Converter added a little check to >> avoid translating the offset of a DateAndTime when it is not needed. >> >> P3Converter>>#convertDateAndTimeWithoutTimezoneFrom: bytes length: >> length description: description >> "TIMESTAMP WITHOUT TIME ZONE (TIMESTAMP) is stored internally in >> Postgres the way it was inserted, its representation remains constant, >> with no offset added. We use the timezone of the connection to do the >> necessary shifting. This assumes that the timezones used during >> insert/update and query are the same." >> >> | timestamp offset | >> timestamp := DateAndTime readFrom: (self asciiStreamFor: bytes >> length: length) defaultOffset: Duration zero. >> offset := self timezone offsetForTimestamp: timestamp. >> ^offset isZero "<-- added this check to avoid translation" >> ifTrue: [ timestamp ] >> ifFalse: [ timestamp translateTo: offset ] >> >> And the speedup went even higher. But I don't know whether this last >> part is correct. >> >> Of course this seems as a quick and dirty fix, but I don't know >> whether DateAndTime>>readFrom: should read any format or just ISO 8601 >> formats nor whether the Date/DateAndTime coming from PostgreSQL are >> always formatted that way. I ran my app's small test suite and haven't >> had any issues, neither during development with these changes applied. >> >> I think there is a significant slowdown involved in the instantiation >> of Dates that should be fixed, whether this fix is definitive or not >> is why I'm asking here. >> >> Regards! >> >> Esteban A. Maringolo >

Oct. 13, 2020

Re: [ANN] Libgit 1.0.0 in Pharo 9

by Sean P. DeNigris

tesonep(a)gmail.com wrote > Esteban is working on having a nice OBS configuration > for the VM extending what Holger has previously done Awesome! I code on Mac, but this is super important to the community and often for deployment... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 13, 2020

Re: This week (41/2020) on the Issue Tracker

by Sean P. DeNigris

Marcus Denker-4 wrote > This week (41/2020) on the Issue Tracker > This one puts a focus on *merged* PRs to Pharo itself only and sorts them > by category with a > little bit of context. Thanks, Marcus! Indeed this one seems much nicer :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 13, 2020