- Pharo-dev - lists.pharo.org

This week (05/2022) on the Pharo Issue Tracker

by Marcus Denker

We merged 15 PRs and closed 31 Issues. Fixes ===== - Increasing minimum size for Calypso browser #10838 https://github.com/pharo-project/pharo/pull/10838 - Add back beautifulcomments #10832 https://github.com/pharo-project/pharo/pull/10832 - 10800-Broken-FT2-library-setting #10851 https://github.com/pharo-project/pharo/pull/10851 Breakpoint interaction ====================== - Breakpoint position from cursor #10812 https://github.com/pharo-project/pharo/pull/10812 - Inserting variable breakpoint when the selected node is variable https://github.com/pharo-project/pharo/pull/10841 Cleanup ======= - Remove Class>>isAbstract as it actually call the super class method #10825 https://github.com/pharo-project/pharo/pull/10825 - Remove Spec1 Critic Browser #10816 https://github.com/pharo-project/pharo/pull/10816 - Remove Spec1 #10818 https://github.com/pharo-project/pharo/pull/10818 - Cleanup-unsent-Deprecated90 #10833 https://github.com/pharo-project/pharo/pull/10833 - fix-users-canBeGlobalVarInitial #10820 https://github.com/pharo-project/pharo/pull/10820 - Cleanup : remove Class>>isValidTraitName. No more sender of it in theâ¦ #10826 https://github.com/pharo-project/pharo/pull/10826 - Replace Moose algos graphs by AI graphs algorithms #10839 https://github.com/pharo-project/pharo/pull/10839 - Integrate Roassal3 v0.9.9e #10846 https://github.com/pharo-project/pharo/pull/10846 Comments ======== - 10214 improving comments and adding tests to tree searcher #10636 https://github.com/pharo-project/pharo/pull/10636 - 10214 improving comments and adding tests to tree searcher #10817 https://github.com/pharo-project/pharo/pull/10817

Feb. 4, 2022

PharoDays'22: Inscriptions are open!

by Guillermo Polito

-------------------------------------------------------------------------------- Pharo Days March 3rd and 4th, Lille, France https://days.pharo.org/ <https://days.pharo.org/> ââââââââââââââââââââââââââââââââââââââââ Inscriptions are open! Do not miss the opportunity to meet the Pharo programming environment and its community! PharoDays is a unique event where you can meet other Pharoers, discover latest advances, and share your experience. Hand-ons sessions are there to help you getting started on advance topics. Follow the "Show us your project" sessions to get immersed in Pharo lively community. This year, PharoDays is a mix of technical talks and hand-ons. Come to join business chat and enjoy friendly atmosphere and discuss with experts. Check the tentative schedule: from building command line interfaces to web applications, through modern desktop applications, visualisations, debugging and even a live music performance! See you in march!

Feb. 1, 2022

Re: FFI help with *** pointers to get font family list

by Martin Dias

On Sat, Jan 29, 2022 at 9:15 PM Stewart MacLean <stewmaclean(a)gmail.com> wrote: > > Hi Martin, > > Thanks for the reply - in fact those methods have just been recently added by Esteban who very kindly sent me the answers! Ah! great :D Are you working in the same or a different repo? MartÃn > > Cheers, > Stewart > > On Sun, Jan 30, 2022 at 1:06 AM Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hello Stewart, >> >> I didn't know how to answer your question, but I've found an >> implementation of the same call. See the send of #listFamilies:count: >> message in: >> https://github.com/pharo-spec/gtk-bindings/blob/9cda0f563023c68714c6c54e6c5… >> >> Cheers, >> MartÃ¬n >> >> On Tue, Jan 25, 2022 at 7:36 AM Stewart MacLean <stewmaclean(a)gmail.com> wrote: >> > >> > Hi, >> > >> > I'm trying to figure out how to implement code to retrieve a list of font families using the Pango libraries. The key function definition is: >> > >> > https://docs.gtk.org/Pango/method.FontMap.list_families.html >> > >> > void >> > pango_font_map_list_families ( >> > PangoFontMap* fontmap, >> > PangoFontFamily*** families, >> > int* n_families >> > ) >> > >> > I've found some C code, which is shown below. The tricky bit is the ***. I've managed to get this working in VisualWorks (code also below), but can't figure out how to do this using the Pharo FFI. >> > >> > I've managed to get the basic Pango functionality going, but I can't figure out how to use ExternalAddress to do this. Running on a MacMini M1. >> > >> > Any pointers (:)) appreciated! >> > >> > Thanks, >> > >> > Stew >> > >> > C Version >> > ---------------- >> > #include <glib.h> >> > #include <pango/pangocairo.h> >> > >> > static void >> > list_fonts () >> > { >> > int i; >> > PangoFontFamily ** families; >> > int n_families; >> > PangoFontMap * fontmap; >> > >> > fontmap = pango_cairo_font_map_get_default(); >> > pango_font_map_list_families (fontmap, & families, & n_families); >> > printf ("There are %d families\n", n_families); >> > for (i = 0; i < n_families; i++) { >> > PangoFontFamily * family = families[i]; >> > const char * family_name; >> > >> > family_name = pango_font_family_get_name (family); >> > printf ("Family %d: %s\n", i, family_name); >> > } >> > g_free (families); >> > } >> > >> > int main (int argc, char ** argv) >> > { >> > list_fonts (); >> > return 0; >> > } >> > >> > ================================= >> > VisualWorks Version >> > --------------------------- >> > availableFamilyNames >> > " >> > Transcript clear. >> > (FontFamily availableFamilyNames asSortedCollection: [: a : b | a < b]) do: [: each | Transcript cr; show: each]. >> > >> > NamedFontSelector open >> > " >> > >> > "08/09/20 SIM. Modified to work on 64bit. >> > Clues obtained from: >> > XSurface class >>displaySurface: >> > DisplaySurface>>cairoVisual >> > PDFSurface class>>versions" >> > >> > | listPointer sizePointer ffPointers result | >> > >> > ObjectMemory is64Bit >> > ifTrue: >> > [listPointer := CIntegerType unsignedLongLong gcMalloc. >> > sizePointer := listPointer sizeof gcCopyToHeap] >> > ifFalse: >> > [listPointer := 0 gcCopyToHeap. >> > sizePointer := 0 gcCopyToHeap]. >> > >> > LibPango default >> > pango_font_map_list_families: LibPango default pango_cairo_font_map_get_default >> > with: listPointer >> > with: sizePointer. >> > >> > ffPointers := >> > (ObjectMemory is64Bit >> > ifTrue: [CIntegerType unsignedLongLong] >> > ifFalse: [ CIntegerType unsignedInt]) >> > newPointerToAddress: listPointer contents. >> > >> > result := OrderedCollection new: sizePointer contents. >> > sizePointer contents timesRepeat: >> > [result >> > add: (LibPango default pango_font_family_get_name: ffPointers contents) utf8. >> > ffPointers += 1]. >> > LibPango default g_free: listPointer contents. >> > ^result >> > >> >

Jan. 31, 2022

Re: ZTimestamp now has nanosecond precision

by stephane ducasse

> On 31 Jan 2022, at 12:09, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > Hi Stef, > > ZTimestamp is meant to be used as an alternative/replacement for DateAndTime. That means that if you need a timestamp representation for which you would normally use DateAndTime, you can use now ZTimestamp. It is more efficient as it is half as large in memory and most operations are faster. It is also simpler. > > However, it is not 100% the same. It does not hold timezone information and is always in UTC, not your local timezone. The idea is that you only convert to/from another timezone when you need to, when reading/writing or in a UI. There is full support for that, but it is a specific approach. > > I am not advocating that ZTimestamp should replace DateAndTime in the standard image. I know :) But I would :) I would prefer to package DateAndTime and use a compact Timestamp. I also really like the idea of a separated functionalities because I barely got what I wanted to be printed in the past in DateAndTime. > I just would like people to be aware that there are alternatives with nice properties (including example based formatting/parsing and full timezone support, both in separate classes). I prefer to use good stuff. S

Jan. 31, 2022

Re: ZTimestamp now has nanosecond precision

by Sven Van Caekenberghe

Hi Stef, ZTimestamp is meant to be used as an alternative/replacement for DateAndTime. That means that if you need a timestamp representation for which you would normally use DateAndTime, you can use now ZTimestamp. It is more efficient as it is half as large in memory and most operations are faster. It is also simpler. However, it is not 100% the same. It does not hold timezone information and is always in UTC, not your local timezone. The idea is that you only convert to/from another timezone when you need to, when reading/writing or in a UI. There is full support for that, but it is a specific approach. I am not advocating that ZTimestamp should replace DateAndTime in the standard image. I just would like people to be aware that there are alternatives with nice properties (including example based formatting/parsing and full timezone support, both in separate classes). Sven > On 30 Jan 2022, at 13:36, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi sven > > Ideally I would like to see the core of Pharo to improve. > In the past I was thinking that we could have a better âtimeâ package but it would become too large. > So now I would like to have > > - possibility to have a nice and compact kernel for pharo internal > - nice loadable libraries such as aconcagua or others > > Now the point of my email. > I would like to see some Z component such as ZTimestamp or ZUrl replace what we have. > > Would it make sense > to rename ZTimestamp as DateAndTime and put in pharo? > or to replace DateAndTime but Ztimestamp renamed Timestamp? > > Now to me when I think about Date and Time I do not think about timestamp but may be they have the same API at the end. > > S > >> On 27 Jan 2022, at 10:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> Last year, I extended ZTimestamp with a default nanosecond precision (it previously had whole second precision). This makes it a more complete replacement for DateAndTime. >> >> https://github.com/svenvc/ztimestamp >> https://github.com/svenvc/ztimestamp/commit/de6c5a670ed0c6cb18894b4917383dd… >> >> The goals of ZTimestamp are to be simpler and more efficient (both faster and more compact). A ZTimestamp instance occupies half the space of a DateAndTime instance, its two slots being SmallIntegers. Back in the 32-bit days, the seconds since midnight field was too small for nanoseconds. Now, 64-bit is the default and there is enough room and no speed penalty for working with nanoseconds since midnight. >> >> In casual use, you won't see much of a difference, apart from the added detail: >> >> ZTimestamp now. "2022-01-27T09:21:20.528695Z" >> >> There are ways to convert to the older precision: >> >> ZTimestamp now truncated. >> ZTimestamp now rounded. >> ZTimestamp nowTruncated. >> >> Obviously, other methods and classes now support this added precision (like ZTimestampFormat). >> >> If you load or depend on tag/release v25 you get the latest version before this major change. >> >> If you encounter any problems please let me know. >> >> Sven

Jan. 31, 2022

Re: ZTimestamp now has nanosecond precision

by stephane ducasse

Hi sven Ideally I would like to see the core of Pharo to improve. In the past I was thinking that we could have a better âtimeâ package but it would become too large. So now I would like to have - possibility to have a nice and compact kernel for pharo internal - nice loadable libraries such as aconcagua or others Now the point of my email. I would like to see some Z component such as ZTimestamp or ZUrl replace what we have. Would it make sense to rename ZTimestamp as DateAndTime and put in pharo? or to replace DateAndTime but Ztimestamp renamed Timestamp? Now to me when I think about Date and Time I do not think about timestamp but may be they have the same API at the end. S > On 27 Jan 2022, at 10:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Last year, I extended ZTimestamp with a default nanosecond precision (it previously had whole second precision). This makes it a more complete replacement for DateAndTime. > > https://github.com/svenvc/ztimestamp > https://github.com/svenvc/ztimestamp/commit/de6c5a670ed0c6cb18894b4917383dd… > > The goals of ZTimestamp are to be simpler and more efficient (both faster and more compact). A ZTimestamp instance occupies half the space of a DateAndTime instance, its two slots being SmallIntegers. Back in the 32-bit days, the seconds since midnight field was too small for nanoseconds. Now, 64-bit is the default and there is enough room and no speed penalty for working with nanoseconds since midnight. > > In casual use, you won't see much of a difference, apart from the added detail: > > ZTimestamp now. "2022-01-27T09:21:20.528695Z" > > There are ways to convert to the older precision: > > ZTimestamp now truncated. > ZTimestamp now rounded. > ZTimestamp nowTruncated. > > Obviously, other methods and classes now support this added precision (like ZTimestampFormat). > > If you load or depend on tag/release v25 you get the latest version before this major change. > > If you encounter any problems please let me know. > > Sven

Jan. 30, 2022

Re: FFI help with *** pointers to get font family list

by Stewart MacLean

Hi Martin, Thanks for the reply - in fact those methods have just been recently added by Esteban who very kindly sent me the answers! Cheers, Stewart On Sun, Jan 30, 2022 at 1:06 AM Martin Dias <tinchodias(a)gmail.com> wrote: > Hello Stewart, > > I didn't know how to answer your question, but I've found an > implementation of the same call. See the send of #listFamilies:count: > message in: > > https://github.com/pharo-spec/gtk-bindings/blob/9cda0f563023c68714c6c54e6c5… > > Cheers, > MartÃ¬n > > On Tue, Jan 25, 2022 at 7:36 AM Stewart MacLean <stewmaclean(a)gmail.com> > wrote: > > > > Hi, > > > > I'm trying to figure out how to implement code to retrieve a list of > font families using the Pango libraries. The key function definition is: > > > > https://docs.gtk.org/Pango/method.FontMap.list_families.html > > > > void > > pango_font_map_list_families ( > > PangoFontMap* fontmap, > > PangoFontFamily*** families, > > int* n_families > > ) > > > > I've found some C code, which is shown below. The tricky bit is the > ***. I've managed to get this working in VisualWorks (code also below), but > can't figure out how to do this using the Pharo FFI. > > > > I've managed to get the basic Pango functionality going, but I can't > figure out how to use ExternalAddress to do this. Running on a MacMini M1. > > > > Any pointers (:)) appreciated! > > > > Thanks, > > > > Stew > > > > C Version > > ---------------- > > #include <glib.h> > > #include <pango/pangocairo.h> > > > > static void > > list_fonts () > > { > > int i; > > PangoFontFamily ** families; > > int n_families; > > PangoFontMap * fontmap; > > > > fontmap = pango_cairo_font_map_get_default(); > > pango_font_map_list_families (fontmap, & families, & n_families); > > printf ("There are %d families\n", n_families); > > for (i = 0; i < n_families; i++) { > > PangoFontFamily * family = families[i]; > > const char * family_name; > > > > family_name = pango_font_family_get_name (family); > > printf ("Family %d: %s\n", i, family_name); > > } > > g_free (families); > > } > > > > int main (int argc, char ** argv) > > { > > list_fonts (); > > return 0; > > } > > > > ================================= > > VisualWorks Version > > --------------------------- > > availableFamilyNames > > " > > Transcript clear. > > (FontFamily availableFamilyNames asSortedCollection: [: a : b | a < b]) > do: [: each | Transcript cr; show: each]. > > > > NamedFontSelector open > > " > > > > "08/09/20 SIM. Modified to work on 64bit. > > Clues obtained from: > > XSurface class >>displaySurface: > > DisplaySurface>>cairoVisual > > PDFSurface class>>versions" > > > > | listPointer sizePointer ffPointers result | > > > > ObjectMemory is64Bit > > ifTrue: > > [listPointer := CIntegerType unsignedLongLong gcMalloc. > > sizePointer := listPointer sizeof gcCopyToHeap] > > ifFalse: > > [listPointer := 0 gcCopyToHeap. > > sizePointer := 0 gcCopyToHeap]. > > > > LibPango default > > pango_font_map_list_families: LibPango default > pango_cairo_font_map_get_default > > with: listPointer > > with: sizePointer. > > > > ffPointers := > > (ObjectMemory is64Bit > > ifTrue: [CIntegerType unsignedLongLong] > > ifFalse: [ CIntegerType unsignedInt]) > > newPointerToAddress: listPointer contents. > > > > result := OrderedCollection new: sizePointer contents. > > sizePointer contents timesRepeat: > > [result > > add: (LibPango default pango_font_family_get_name: ffPointers > contents) utf8. > > ffPointers += 1]. > > LibPango default g_free: listPointer contents. > > ^result > > > > >

Jan. 30, 2022

Re: FFI help with *** pointers to get font family list

by Martin Dias

Hello Stewart, I didn't know how to answer your question, but I've found an implementation of the same call. See the send of #listFamilies:count: message in: https://github.com/pharo-spec/gtk-bindings/blob/9cda0f563023c68714c6c54e6c5… Cheers, MartÃ¬n On Tue, Jan 25, 2022 at 7:36 AM Stewart MacLean <stewmaclean(a)gmail.com> wrote: > > Hi, > > I'm trying to figure out how to implement code to retrieve a list of font families using the Pango libraries. The key function definition is: > > https://docs.gtk.org/Pango/method.FontMap.list_families.html > > void > pango_font_map_list_families ( > PangoFontMap* fontmap, > PangoFontFamily*** families, > int* n_families > ) > > I've found some C code, which is shown below. The tricky bit is the ***. I've managed to get this working in VisualWorks (code also below), but can't figure out how to do this using the Pharo FFI. > > I've managed to get the basic Pango functionality going, but I can't figure out how to use ExternalAddress to do this. Running on a MacMini M1. > > Any pointers (:)) appreciated! > > Thanks, > > Stew > > C Version > ---------------- > #include <glib.h> > #include <pango/pangocairo.h> > > static void > list_fonts () > { > int i; > PangoFontFamily ** families; > int n_families; > PangoFontMap * fontmap; > > fontmap = pango_cairo_font_map_get_default(); > pango_font_map_list_families (fontmap, & families, & n_families); > printf ("There are %d families\n", n_families); > for (i = 0; i < n_families; i++) { > PangoFontFamily * family = families[i]; > const char * family_name; > > family_name = pango_font_family_get_name (family); > printf ("Family %d: %s\n", i, family_name); > } > g_free (families); > } > > int main (int argc, char ** argv) > { > list_fonts (); > return 0; > } > > ================================= > VisualWorks Version > --------------------------- > availableFamilyNames > " > Transcript clear. > (FontFamily availableFamilyNames asSortedCollection: [: a : b | a < b]) do: [: each | Transcript cr; show: each]. > > NamedFontSelector open > " > > "08/09/20 SIM. Modified to work on 64bit. > Clues obtained from: > XSurface class >>displaySurface: > DisplaySurface>>cairoVisual > PDFSurface class>>versions" > > | listPointer sizePointer ffPointers result | > > ObjectMemory is64Bit > ifTrue: > [listPointer := CIntegerType unsignedLongLong gcMalloc. > sizePointer := listPointer sizeof gcCopyToHeap] > ifFalse: > [listPointer := 0 gcCopyToHeap. > sizePointer := 0 gcCopyToHeap]. > > LibPango default > pango_font_map_list_families: LibPango default pango_cairo_font_map_get_default > with: listPointer > with: sizePointer. > > ffPointers := > (ObjectMemory is64Bit > ifTrue: [CIntegerType unsignedLongLong] > ifFalse: [ CIntegerType unsignedInt]) > newPointerToAddress: listPointer contents. > > result := OrderedCollection new: sizePointer contents. > sizePointer contents timesRepeat: > [result > add: (LibPango default pango_font_family_get_name: ffPointers contents) utf8. > ffPointers += 1]. > LibPango default g_free: listPointer contents. > ^result > >

Jan. 29, 2022

This week (04/2022) on the Pharo Issue Tracker

by Marcus Denker

We merged 23 PRs and closed 24 Issue Tracker entries Fixes ===== - Fix 10741: Adding an unknown SharedPool and canceling the proposed choice brings a debugger #10808 https://github.com/pharo-project/pharo/pull/10808 - 10695-CmdBrowse-raise-a-DNU #10775 https://github.com/pharo-project/pharo/pull/10775 - Rename "Hier" to "Hierarchy" in scopes of refactoring #10778 https://github.com/pharo-project/pharo/pull/10796 - Fix #10698: Misleading Calypso warning when defining new instance variables #10806 https://github.com/pharo-project/pharo/pull/10806 - Fix #7952: Decompiler raises Error For methods from Traits on class side #10807 https://github.com/pharo-project/pharo/pull/10807 - Fix #8630: fix allInstVarNames for Traits with State #10811 https://github.com/pharo-project/pharo/pull/10811 Spec2 ===== - 10721-Porting-ExternalBrowser-to-Spec2-and-remove-Spec1-version #10776 https://github.com/pharo-project/pharo/pull/10776 - 10722-Porting-ChangesBrowser-to-Spec2-and-remove-Spec1-version #10786 https://github.com/pharo-project/pharo/pull/10786 - Load Spec2-Transformations package after Refactoring-Core is loaded #10789 https://github.com/pharo-project/pharo/pull/10789 - spec2 auto-rewrites #10791 https://github.com/pharo-project/pharo/pull/10791 - commit spec rewrites 2 #10792 https://github.com/pharo-project/pharo/pull/10792 - Rename defaultSpec to defaultLayout #10793 https://github.com/pharo-project/pharo/pull/10793 - Move Dependency Analyzer to Spec2 #10813 https://github.com/pharo-project/pharo/pull/10813 Cleanup ======= - testNoUncategorizedMethods-false-positives #10785 https://github.com/pharo-project/pharo/pull/10785 - AST-Tag-Abstract-classes #10783 https://github.com/pharo-project/pharo/pull/10783 - chore: Define baseline of TaskIt for Pharo 10 #10799 https://github.com/pharo-project/pharo/pull/10799 - Using "adding-removing" instead of "adding/removing" #10622 https://github.com/pharo-project/pharo/pull/10622 - Cleanup-canBeExecutedInContext #10784 https://github.com/pharo-project/pharo/pull/10784 - NewValueHolder extracted to its own baseline #10763 https://github.com/pharo-project/pharo/pull/10763 - Updated Fuel to 3.0.4 #10513 https://github.com/pharo-project/pharo/pull/10513 - Cleanup-gtInspectorAllVariablesIn #10809 https://github.com/pharo-project/pharo/pull/10809

Jan. 28, 2022

ZTimestamp now has nanosecond precision

by Sven Van Caekenberghe

Hi, Last year, I extended ZTimestamp with a default nanosecond precision (it previously had whole second precision). This makes it a more complete replacement for DateAndTime. https://github.com/svenvc/ztimestamp https://github.com/svenvc/ztimestamp/commit/de6c5a670ed0c6cb18894b4917383dd… The goals of ZTimestamp are to be simpler and more efficient (both faster and more compact). A ZTimestamp instance occupies half the space of a DateAndTime instance, its two slots being SmallIntegers. Back in the 32-bit days, the seconds since midnight field was too small for nanoseconds. Now, 64-bit is the default and there is enough room and no speed penalty for working with nanoseconds since midnight. In casual use, you won't see much of a difference, apart from the added detail: ZTimestamp now. "2022-01-27T09:21:20.528695Z" There are ways to convert to the older precision: ZTimestamp now truncated. ZTimestamp now rounded. ZTimestamp nowTruncated. Obviously, other methods and classes now support this added precision (like ZTimestampFormat). If you load or depend on tag/release v25 you get the latest version before this major change. If you encounter any problems please let me know. Sven

Jan. 27, 2022