March 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource

by Ben Coman

On Thu, Mar 16, 2017 at 1:25 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > This is a recurring issue. It would be cool if some magic(TM) could raise a dialog with an explanation and pull-down list to select an encoding - but maybe that is too much hand holding. > > The problem is that the server serves a resource, in this case text/html, without specifying its encoding. I just bumped into [1] while browsing around to learn more, but I don't know fully how to interpret it. What do you make of it saying "An XHTML5 document is served as XML and has XML syntax. XML parsers do not recognise the encoding declarations in meta elements. They only recognise the XML declaration. Here is an example: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html .... compared to the page having... <?xml version="1.0" encoding="iso-8859-1"?> cheers -ben [1] https://www.w3.org/International/questions/qa-html-encoding-declarations > > Today, when no encoding is specified, we default to UTF-8. In this case the server silently serves a resource which is ISO-8895-1 encoded. > > The error is triggered by accessing the following URL: > > ZnClient new get: 'http://squeaksource.com/ical/?C=M;O%3DD'; yourself. > > If you inspect the response object inside the http client, you will see that the content-type is text/html. So Zn parses the incoming text using UTF-8 which fails (Zn encoders are strict by default). > > Here is how to change the default during a call: > > ZnDefaultCharacterEncoder > value: ZnCharacterEncoder iso88591 > during: [ ZnClient new get: 'http://squeaksource.com/ical/?C=M;O%3DD'; yourself ]. > > The solution would be that the server adds the proper charset specification. > > Consider the default in Pharo: > > ZnMimeType textHtml => text/html;charset=utf-8 > > The server should serve this resource using the following Content-Type: > > text/html;charset=iso-8859-1 > > This is the server's responsibility. The page in question is the MC index page, which would normally be dynamically generated. Somewhere the server decides on the encoding. That encoding does not have to change, but it should be properly indicated in the HTTP response headers. > > HTH, > > Sven > > > On 15 Mar 2017, at 17:42, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > squeaksource.com is still running on a quite old image, and I know that it > > has problems with multibyte characters. If you are seeing problems related > > to this, it's not the fault of Zinc. > > > > If you can confirm that this is what is happening, then I guess it is time > > to update that trusty old squeaksource.com image :-) > > > > Dave > > > >> On Wed, Mar 15, 2017 at 8:19 PM, Patrick R. <patrick.rein(a)hpi.de> wrote: > >>> > >>> Hi everyone, > >>> > >>> I have been working on bringing http://squeaksource.com/ical/ up to > >>> speed > >>> for Squeak and wanted to make sure that it also works for Pharo. > >> Therefore, > >>> I have created a travis build job for Squeak and Pharo > >>> (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which > >> pulls > >>> the source from squeaksource.com. > >>> > >>> Now the issue is that loading the package in Pharo fails with a > >>> GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this > >>> might be the result of the squeaksource page delivering the page as > >>> iso-8859-1 as it contains special characters. Any ideas on how to get > >>> this > >>> to work? I do not have access to the ical repository description and I > >> would > >>> like to avoid mirroring the whole repository on GitHub. > >> > >> > >> In a fresh 60437 image, in Playground evaluating... > >> > >> Metacello new > >> configuration: 'ICal'; > >> repository: 'github://codeZeilen/ical-smalltalk:master/repository'; > >> onConflict: [:ex | ex allow]; > >> load. > >> ==> Could not resolve: ICal-Core [ICal-Core-PaulDeBruicker.5] in > >> /home/ben/.local/share/Pharo/images/60437-01/pharo-local/package-cache > >> http://squeaksource.com/ical ERROR: 'GoferRepositoryError: Could not > >> access > >> http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for > >> utf-8 encoding' > >> > >> > >> In a new fresh 60437 Image (i.e. empty package-cache) > >> World menu > Monticello > +Repository > squeaksource.com... > >> MCSqueaksourceRepository > >> location: 'http://squeaksource.com/ical' > >> user: '' > >> password: '' > >> ==> open repository then errors "MCRepositoryError: Could not access > >> http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for > >> utf-8 encoding" > >> > >> > >> In Chrome, opening http://www.squeaksource.com/ical > >> then clicking <Versions> > >> and the browser's View Page Source, > >> I see... > >> <?xml version="1.0" encoding="iso-8859-1"?> > >> > >> Googling: zinc iso-8859-1 > >> finds... > >> http://forum.world.st/Problem-using-Zinc-in-Pharo-4-Moose-5-1-td4825329.html > >> but "ZnByteEncoder iso88591" > >> errors with "KeyNotFound: key 'iso88591' not found in Dictionary" > >> and inspecting "ZnByteEncoder byteTextConverters keys sorted" > >> confirms this key is missing (@Sven, I'm curious why was this removed? ) > >> > >> > >> Now https://en.wikipedia.org/wiki/ISO/IEC_8859-1 > >> indicates IBM819 is an alias > >> and " ZnByteEncoder newForEncoding: 'ibm819' " > >> works okay > >> > >> So in MCHttpRepository>>#loadAllFileNames > >> changing... > >> queryAt: 'C' put: 'M;O=D' ; > >> get. > >> to... > >> queryAt: 'C' put: 'M;O=D' . > >> ZnDefaultCharacterEncoder > >> value: (ZnByteEncoder newForEncoding: 'ibm819') > >> during: [client get]. > >> > >> Then from Monticello opening the previously defined > >> http://squeaksource.com/ical > >> works!! > >> > >> > >> Now I was hoping that reverting #loadAllFileNames > >> and in Playground doing... > >> converters := ZnByteEncoder byteTextConverters. > >> converters at: 'iso-8859-1' put: (converters at: 'ibm819'). > >> might alleviate the problem, but no luck. > >> > >> > >> Anyone know a better way to deal with this that hardcoding the encoding > >> into #loadAllFileNames? > >> > >> cheers -ben > >> > > > > > > > >

March 15, 2017

Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource

by Rein, Patrick

Thanks for looking into this :) @Dave: Can you explain what you would have expected to happen here? I see the point that squeaksource could also encode the response as UTF-8. However, currently the page is correctly encoded and delivered in iso-8859-1. From the error message I read that Zinc is nevertheless trying to decode it as UTF-8 which fails when it encounters a character with a code point > 127. Bests Patrick ________________________________________ From: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> on behalf of David T. Lewis <lewis(a)mail.msen.com> Sent: Wednesday, March 15, 2017 17:42 To: Pharo Development List Subject: Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource squeaksource.com is still running on a quite old image, and I know that it has problems with multibyte characters. If you are seeing problems related to this, it's not the fault of Zinc. If you can confirm that this is what is happening, then I guess it is time to update that trusty old squeaksource.com image :-) Dave > On Wed, Mar 15, 2017 at 8:19 PM, Patrick R. <patrick.rein(a)hpi.de> wrote: >> >> Hi everyone, >> >> I have been working on bringing http://squeaksource.com/ical/ up to >> speed >> for Squeak and wanted to make sure that it also works for Pharo. > Therefore, >> I have created a travis build job for Squeak and Pharo >> (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which > pulls >> the source from squeaksource.com. >> >> Now the issue is that loading the package in Pharo fails with a >> GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this >> might be the result of the squeaksource page delivering the page as >> iso-8859-1 as it contains special characters. Any ideas on how to get >> this >> to work? I do not have access to the ical repository description and I > would >> like to avoid mirroring the whole repository on GitHub. > > > In a fresh 60437 image, in Playground evaluating... > > Metacello new > configuration: 'ICal'; > repository: 'github://codeZeilen/ical-smalltalk:master/repository'; > onConflict: [:ex | ex allow]; > load. > ==> Could not resolve: ICal-Core [ICal-Core-PaulDeBruicker.5] in > /home/ben/.local/share/Pharo/images/60437-01/pharo-local/package-cache > http://squeaksource.com/ical ERROR: 'GoferRepositoryError: Could not > access > http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for > utf-8 encoding' > > > In a new fresh 60437 Image (i.e. empty package-cache) > World menu > Monticello > +Repository > squeaksource.com... > MCSqueaksourceRepository > location: 'http://squeaksource.com/ical' > user: '' > password: '' > ==> open repository then errors "MCRepositoryError: Could not access > http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for > utf-8 encoding" > > > In Chrome, opening http://www.squeaksource.com/ical > then clicking <Versions> > and the browser's View Page Source, > I see... > <?xml version="1.0" encoding="iso-8859-1"?> > > Googling: zinc iso-8859-1 > finds... > http://forum.world.st/Problem-using-Zinc-in-Pharo-4-Moose-5-1-td4825329.html > but "ZnByteEncoder iso88591" > errors with "KeyNotFound: key 'iso88591' not found in Dictionary" > and inspecting "ZnByteEncoder byteTextConverters keys sorted" > confirms this key is missing (@Sven, I'm curious why was this removed? ) > > > Now https://en.wikipedia.org/wiki/ISO/IEC_8859-1 > indicates IBM819 is an alias > and " ZnByteEncoder newForEncoding: 'ibm819' " > works okay > > So in MCHttpRepository>>#loadAllFileNames > changing... > queryAt: 'C' put: 'M;O=D' ; > get. > to... > queryAt: 'C' put: 'M;O=D' . > ZnDefaultCharacterEncoder > value: (ZnByteEncoder newForEncoding: 'ibm819') > during: [client get]. > > Then from Monticello opening the previously defined > http://squeaksource.com/ical > works!! > > > Now I was hoping that reverting #loadAllFileNames > and in Playground doing... > converters := ZnByteEncoder byteTextConverters. > converters at: 'iso-8859-1' put: (converters at: 'ibm819'). > might alleviate the problem, but no luck. > > > Anyone know a better way to deal with this that hardcoding the encoding > into #loadAllFileNames? > > cheers -ben >

March 15, 2017

Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource

by Sven Van Caekenberghe

Hi, This is a recurring issue. The problem is that the server serves a resource, in this case text/html, without specifying its encoding. Today, when no encoding is specified, we default to UTF-8. In this case the server silently serves a resource which is ISO-8895-1 encoded. The error is triggered by accessing the following URL: ZnClient new get: 'http://squeaksource.com/ical/?C=M;O%3DD'; yourself. If you inspect the response object inside the http client, you will see that the content-type is text/html. So Zn parses the incoming text using UTF-8 which fails (Zn encoders are strict by default). Here is how to change the default during a call: ZnDefaultCharacterEncoder value: ZnCharacterEncoder iso88591 during: [ ZnClient new get: 'http://squeaksource.com/ical/?C=M;O%3DD'; yourself ]. The solution would be that the server adds the proper charset specification. Consider the default in Pharo: ZnMimeType textHtml => text/html;charset=utf-8 The server should serve this resource using the following Content-Type: text/html;charset=iso-8859-1 This is the server's responsibility. The page in question is the MC index page, which would normally be dynamically generated. Somewhere the server decides on the encoding. That encoding does not have to change, but it should be properly indicated in the HTTP response headers. HTH, Sven > On 15 Mar 2017, at 17:42, David T. Lewis <lewis(a)mail.msen.com> wrote: > > squeaksource.com is still running on a quite old image, and I know that it > has problems with multibyte characters. If you are seeing problems related > to this, it's not the fault of Zinc. > > If you can confirm that this is what is happening, then I guess it is time > to update that trusty old squeaksource.com image :-) > > Dave > >> On Wed, Mar 15, 2017 at 8:19 PM, Patrick R. <patrick.rein(a)hpi.de> wrote: >>> >>> Hi everyone, >>> >>> I have been working on bringing http://squeaksource.com/ical/ up to >>> speed >>> for Squeak and wanted to make sure that it also works for Pharo. >> Therefore, >>> I have created a travis build job for Squeak and Pharo >>> (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which >> pulls >>> the source from squeaksource.com. >>> >>> Now the issue is that loading the package in Pharo fails with a >>> GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this >>> might be the result of the squeaksource page delivering the page as >>> iso-8859-1 as it contains special characters. Any ideas on how to get >>> this >>> to work? I do not have access to the ical repository description and I >> would >>> like to avoid mirroring the whole repository on GitHub. >> >> >> In a fresh 60437 image, in Playground evaluating... >> >> Metacello new >> configuration: 'ICal'; >> repository: 'github://codeZeilen/ical-smalltalk:master/repository'; >> onConflict: [:ex | ex allow]; >> load. >> ==> Could not resolve: ICal-Core [ICal-Core-PaulDeBruicker.5] in >> /home/ben/.local/share/Pharo/images/60437-01/pharo-local/package-cache >> http://squeaksource.com/ical ERROR: 'GoferRepositoryError: Could not >> access >> http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for >> utf-8 encoding' >> >> >> In a new fresh 60437 Image (i.e. empty package-cache) >> World menu > Monticello > +Repository > squeaksource.com... >> MCSqueaksourceRepository >> location: 'http://squeaksource.com/ical' >> user: '' >> password: '' >> ==> open repository then errors "MCRepositoryError: Could not access >> http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for >> utf-8 encoding" >> >> >> In Chrome, opening http://www.squeaksource.com/ical >> then clicking <Versions> >> and the browser's View Page Source, >> I see... >> <?xml version="1.0" encoding="iso-8859-1"?> >> >> Googling: zinc iso-8859-1 >> finds... >> http://forum.world.st/Problem-using-Zinc-in-Pharo-4-Moose-5-1-td4825329.html >> but "ZnByteEncoder iso88591" >> errors with "KeyNotFound: key 'iso88591' not found in Dictionary" >> and inspecting "ZnByteEncoder byteTextConverters keys sorted" >> confirms this key is missing (@Sven, I'm curious why was this removed? ) >> >> >> Now https://en.wikipedia.org/wiki/ISO/IEC_8859-1 >> indicates IBM819 is an alias >> and " ZnByteEncoder newForEncoding: 'ibm819' " >> works okay >> >> So in MCHttpRepository>>#loadAllFileNames >> changing... >> queryAt: 'C' put: 'M;O=D' ; >> get. >> to... >> queryAt: 'C' put: 'M;O=D' . >> ZnDefaultCharacterEncoder >> value: (ZnByteEncoder newForEncoding: 'ibm819') >> during: [client get]. >> >> Then from Monticello opening the previously defined >> http://squeaksource.com/ical >> works!! >> >> >> Now I was hoping that reverting #loadAllFileNames >> and in Playground doing... >> converters := ZnByteEncoder byteTextConverters. >> converters at: 'iso-8859-1' put: (converters at: 'ibm819'). >> might alleviate the problem, but no luck. >> >> >> Anyone know a better way to deal with this that hardcoding the encoding >> into #loadAllFileNames? >> >> cheers -ben >> > > >

March 15, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolas Cellier

2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > sorry for coming late to this threadâ¦ hard week :) > why we are trying to compile with cygwin? > is there a problem with the mingw distro? > > I didnât have the time to update the README, sadly. But wellâ¦ following > appveyor configuration should give you all you need to reproduce the build > (thatâs what I did last time I built an environment). > > Esteban > > > Hi Esteban, How did you solve the directx problem? > On 15 Mar 2017, at 10:11, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be <philippe.back@ > gmail.com>: > >> I made my own build here. >> Not up to date with latest stuff but should work for the build process. >> >> https://ci.appveyor.com/project/philippeback/pharo-vm >> >> It uses my forked repo and provided you set your own bintray env vars for >> API keys will publish there. >> >> Check all of the output of env vars and where/which in the appveyor >> console to see what gets used when when it comes to compilers and so on as >> there were various compiler versions involved at one point. >> >> Third party cache part is also worth checking. >> >> Still not able to build on my local box at the moment due to some tools >> discrepancies happening. >> >> My build artifacts are embarking too much at this point but allow you ro >> get the release, debug, and assert vms for windows. This helps when >> debugging as backtraces and so on are much more meaningful and one can use >> gdb more effectively to understand what is going on. >> >> Just keep the dlls and exes and you'll be fine. >> > > Ah good, thank you. > > > >> >> HTH >> >> Phil >> >> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : >> >>> >>> >>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka. >>> nice(a)gmail.com>: >>> >>>> >>>> >>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka. >>>> nice(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka. >>>>>> nice(a)gmail.com>: >>>>>> >>>>>>> Hi Nicolai, >>>>>>> >>>>>>> If you look at appveyor.yml configuration on https://github.com/ >>>>>>> OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml, you will see >>>>>>> that the pharo brand is not yet in the matrix. >>>>>>> >>>>>>> It's because builds are based on cygwin, but as I understood, some >>>>>>> library used by some plugin required by pharo refuse to compile with >>>>>>> cygwin. They appear to work with mingw32. >>>>>>> Cygwin provides headers for legacy directx, some distribution of >>>>>>> mingw32 did in the past, but it does not seem the case anymore. >>>>>>> Using the directx headers from Microsoft SDK is a problem. They are >>>>>>> not redistributable and can't be found anymore on the net (too old). We >>>>>>> cannot seriously base the builds on something so fragile (both technically >>>>>>> and legally) in the long term. >>>>>>> >>>>>>> Also, the 64 bits VM does only work with clang, and we don't have >>>>>>> anything available as a 64bits Microsoft SDK... So pharo has to fix that >>>>>>> too. >>>>>>> >>>>>>> In the interim, you should look at https://github.com/pharo- >>>>>>> project/pharo-vm/blob/master/.appveyor.yml and follow the scripts >>>>>>> there. >>>>>>> >>>>>> >>>>>> Ok, thank you. >>>>>> >>>>>> >>>>> >>>>> I gave it a shot on sunday, because it was particularly rainy in >>>>> Nantes, and I almost succeeded in compiling all the dependencies with >>>>> cygwin. >>>>> Well, I mean with autotools cmake libtool pkg-config and I surely >>>>> forget a few other niceties that some not so well informed programmers >>>>> committed with the faith that it would make their life "easier". It >>>>> certainly does not make mine simpler... >>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it >>>>> seems that the workaround of Igor does not work anymore. >>>>> ssize_t, WTF??? >>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll >>>>> publish the branch to see how far appveyor goes. >>>>> >>>>> >>>>> >>>> >>>> So I solved the ssize_t problem by removing the hack from Igor which is >>>> not necessary anymore... >>>> But got another problem soon after while building the tests... >>>> There are trailing lines generated at end of >>>> tests/cairo-test-constructors.c that make the compilation fail: >>>> >>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>>> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensm >>>> alltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty- >>>> cache/windows/i386/include/libpng16 -Wall -Wextra >>>> -Wmissing-declarations -Werror-implicit-function-declaration >>>> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum >>>> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 >>>> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>>> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm >>>> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c >>>> -o cairo_test_suite-cairo-test-constructors.o `test -f >>>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de donnÃ©es >>>> n'a pas de type ni de classe de stockage >>>> oning (); >>>> ^ >>>> cairo-test-constructors.c:1118:1: attention : type defaults to âintâ >>>> in declaration of âoningâ [-Wimplicit-int] >>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de donnÃ©es >>>> n'a pas de type ni de classe de stockage >>>> _register_ft_show_glyphs_table (); >>>> ^ >>>> >>>> And the file looks like it has obviously been overwritten, but not >>>> truncated !!! >>>> >>>> ... >>>> extern void _register_multi_page (void); >>>> extern void _register_fallback_resolution (void); >>>> >>>> void >>>> _cairo_test_runner_register_tests (void) >>>> { >>>> _register_a1_bug (); >>>> _register_a1_clip_paint (); >>>> ... >>>> _register_multi_page (); >>>> _register_fallback_resolution (); >>>> } >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *oning (); _register_ft_show_glyphs_table >>>> (); _register_ft_text_vertical_layout_type1 >>>> (); _register_ft_text_vertical_layout_type3 >>>> (); _register_ft_text_antialias_none (); _register_ps_eps >>>> (); _register_ps_features (); _register_ps_surface_source >>>> (); _register_svg_surface (); _register_svg_clip >>>> (); _register_svg_surface_source (); _register_multi_page >>>> (); _register_fallback_resolution ();}* >>>> >>>> This file is generated by a shell script test/make-cairo-test-construct >>>> ors.sh >>>> I can't find any reference of the bug, and upgrade to version 1.14.8 >>>> does not solve the issue. >>>> So it will wait until tomorrow... >>>> >>> >>> >>> I got the build for windows with mingw nearly working. (it can not build >>> some plugins, like SqueakSSL for windows, because the used wincrypt.h is >>> different in the mingw distrubtion). >>> >>> I still have the problem, that there seems to be a preprocessing step , >>> that should put the vm-version (and source timestamp) in the >>> *sqSCCSVersion.h* >>> I got this working by running .travis_build.sh (with the options for >>> arch/flavor/platform) But how is this done normally when you build a vm >>> locally? >>> And how is this done for the pharo-vm we currently use? >>> >>> >>> >>>> >>>> Nicolas >>>> >>>> >>>>>>> I hope that Esteban will find time to resolve all these problems and >>>>>>> have pharo brand back on opensmalltalk-vm. I guess that any form of help is >>>>>>> welcome. >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>> >>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>> >>>>>>>> I still have problems building a vm on windows. >>>>>>>> can you give me some hints how to start ? >>>>>>>> I cloned the recent pharo-vm project, >>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>>>>> run >>>>>>>> mvm >>>>>>>> >>>>>>>> But I got a couple of problems (mingw-32 compiler commands not >>>>>>>> found, I had to adjust the include path for finding directx header, missing >>>>>>>> variable replacement for git-versions). >>>>>>>> So I may miss some important steps. >>>>>>>> Is there a repository where I can clone the mingw environment used >>>>>>>> to build the win32-pharo-vm, the environment used on the build-server ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Nicolai >>>>>>>> >>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com> >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I believe they're built from* https://github.com/OpenSmalltalk/vm >>>>>>>>>>>> <https://github.com/OpenSmalltalk/vm>* using travis and >>>>>>>>>>>> appveyor. On the gitbhub readme there are relevant links. All built >>>>>>>>>>>> artifacts are also kept on bintray for history. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Thank you! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> no, they arenât :) >>>>>>>>>>> instead, they are built here: https://github.com/pharo >>>>>>>>>>> -project/pharo-vm >>>>>>>>>>> >>>>>>>>>>> (README still not updated) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> what did changed ? I am not able to build the vm on windows >>>>>>>>>> anymore (something wrong with generating the generator.image, I'll now >>>>>>>>>> reset my local pharo-vm build directory and see if it works afterwards). >>>>>>>>>> >>>>>>>>> >>>>>>>>> see attached the stderr log : >>>>>>>>> >>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa >>>>>>>>> dVMMaker.st' >>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>>>>>> BaseSoundSystem class>>initialize >>>>>>>>> MCMethodDefinition>>postloadOver: >>>>>>>>> >>>>>>>>> .... >>>>>>>>> >>>>>>>>> >>>>>>>>>> Are we still working with branch spur-64, or are we back on >>>>>>>>>> master ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Esteban >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < >>>>>>>>>>>> nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>>>>>>>>>>>> I don't see them on the build server, only the buildresults at >>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>>>>>>>>>> >>>>>>>>>>>>> The latest builds on the buildserver are from the last year >>>>>>>>>>>>> only. >>>>>>>>>>>>> >>>>>>>>>>>>> nicolai >>>>>>>>>>>>> >>>>>>>>>>>> >

March 15, 2017

Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource

by David T. Lewis

squeaksource.com is still running on a quite old image, and I know that it has problems with multibyte characters. If you are seeing problems related to this, it's not the fault of Zinc. If you can confirm that this is what is happening, then I guess it is time to update that trusty old squeaksource.com image :-) Dave > On Wed, Mar 15, 2017 at 8:19 PM, Patrick R. <patrick.rein(a)hpi.de> wrote: >> >> Hi everyone, >> >> I have been working on bringing http://squeaksource.com/ical/ up to >> speed >> for Squeak and wanted to make sure that it also works for Pharo. > Therefore, >> I have created a travis build job for Squeak and Pharo >> (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which > pulls >> the source from squeaksource.com. >> >> Now the issue is that loading the package in Pharo fails with a >> GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this >> might be the result of the squeaksource page delivering the page as >> iso-8859-1 as it contains special characters. Any ideas on how to get >> this >> to work? I do not have access to the ical repository description and I > would >> like to avoid mirroring the whole repository on GitHub. > > > In a fresh 60437 image, in Playground evaluating... > > Metacello new > configuration: 'ICal'; > repository: 'github://codeZeilen/ical-smalltalk:master/repository'; > onConflict: [:ex | ex allow]; > load. > ==> Could not resolve: ICal-Core [ICal-Core-PaulDeBruicker.5] in > /home/ben/.local/share/Pharo/images/60437-01/pharo-local/package-cache > http://squeaksource.com/ical ERROR: 'GoferRepositoryError: Could not > access > http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for > utf-8 encoding' > > > In a new fresh 60437 Image (i.e. empty package-cache) > World menu > Monticello > +Repository > squeaksource.com... > MCSqueaksourceRepository > location: 'http://squeaksource.com/ical' > user: '' > password: '' > ==> open repository then errors "MCRepositoryError: Could not access > http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for > utf-8 encoding" > > > In Chrome, opening http://www.squeaksource.com/ical > then clicking <Versions> > and the browser's View Page Source, > I see... > <?xml version="1.0" encoding="iso-8859-1"?> > > Googling: zinc iso-8859-1 > finds... > http://forum.world.st/Problem-using-Zinc-in-Pharo-4-Moose-5-1-td4825329.html > but "ZnByteEncoder iso88591" > errors with "KeyNotFound: key 'iso88591' not found in Dictionary" > and inspecting "ZnByteEncoder byteTextConverters keys sorted" > confirms this key is missing (@Sven, I'm curious why was this removed? ) > > > Now https://en.wikipedia.org/wiki/ISO/IEC_8859-1 > indicates IBM819 is an alias > and " ZnByteEncoder newForEncoding: 'ibm819' " > works okay > > So in MCHttpRepository>>#loadAllFileNames > changing... > queryAt: 'C' put: 'M;O=D' ; > get. > to... > queryAt: 'C' put: 'M;O=D' . > ZnDefaultCharacterEncoder > value: (ZnByteEncoder newForEncoding: 'ibm819') > during: [client get]. > > Then from Monticello opening the previously defined > http://squeaksource.com/ical > works!! > > > Now I was hoping that reverting #loadAllFileNames > and in Playground doing... > converters := ZnByteEncoder byteTextConverters. > converters at: 'iso-8859-1' put: (converters at: 'ibm819'). > might alleviate the problem, but no luck. > > > Anyone know a better way to deal with this that hardcoding the encoding > into #loadAllFileNames? > > cheers -ben >

March 15, 2017

Re: [Pharo-dev] How to listen for microsoft os windows messages (WM_MESSAGE's)?

by Dimitris Chloupis

True but if you want to work with GUI and Graphics APIs its C++ all the way. Mainly because Graphics are extremely complex data that benefits from the workflow of OOP and the performance of C. Combine the two and you have C++. The language we all love to hate. I have not tried myself , but I think C++ compilers have an option for disabling name mangling that is the reasons UFFI cannot use C++ libraries. But there is of course always the option of making a wrapper DLL in C++ that has no name mangling with EXTERN C keyword. On Tue, Mar 14, 2017 at 4:23 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > you cannot use QT out of the box because is C++ > > I have some experiments with GTK3 that were working but event loop was > kinda failing (no time to go back to it soon). > It would be very interesting to have native windows support, I may take a > look eventually :) > > Esteban > > On 14 Mar 2017, at 13:37, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > There are other cross platform APIs e.g. wxWidgets and Gtk > > There used to be a version of squeak with wx bindings wxSqueak but the > code seems not to be on line now. > > > GTK is not a very good choice, it works well on Linux but on MacOS and > Windows has many issues and a lot less developers bug fixing. > > wxWidgets is a nice GUI API but again it does not come remotely close to > the feature set and stability of QT. Some of its areas also are abandoned > or very much lagging behind. In my case a big turn off was the outdated > python wrappers which sent me directly back to QT. > > When it comes to guis No1 is Native GUIs , No2 is QT. > > But QT needs a commercial license for developing pro applications. Its > free license is GLP which limits the usage on commercial projects. > > It does however offer a free LGPL version with more limited features. LGPL > allows to close code as long as the code is distributed via dynamically > linked libraries. > > Still it may be tricky to balance on the LGPL without falling down. Which > is why many like us prefer MIT over LGPL. > > There are a ton of open source GUI APIs out there, but most of them are > immature, limited or plain abandoned. So you have plenty of choice, but I > think you will have little reason to prefer something that is not QT, > especially if we are talking about commercial projects that need to run on > many platforms. > > >

March 15, 2017

Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource

by Ben Coman

On Wed, Mar 15, 2017 at 8:19 PM, Patrick R. <patrick.rein(a)hpi.de> wrote: > > Hi everyone, > > I have been working on bringing http://squeaksource.com/ical/ up to speed > for Squeak and wanted to make sure that it also works for Pharo. Therefore, > I have created a travis build job for Squeak and Pharo > (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which pulls > the source from squeaksource.com. > > Now the issue is that loading the package in Pharo fails with a > GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this > might be the result of the squeaksource page delivering the page as > iso-8859-1 as it contains special characters. Any ideas on how to get this > to work? I do not have access to the ical repository description and I would > like to avoid mirroring the whole repository on GitHub. In a fresh 60437 image, in Playground evaluating... Metacello new configuration: 'ICal'; repository: 'github://codeZeilen/ical-smalltalk:master/repository'; onConflict: [:ex | ex allow]; load. ==> Could not resolve: ICal-Core [ICal-Core-PaulDeBruicker.5] in /home/ben/.local/share/Pharo/images/60437-01/pharo-local/package-cache http://squeaksource.com/ical ERROR: 'GoferRepositoryError: Could not access http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for utf-8 encoding' In a new fresh 60437 Image (i.e. empty package-cache) World menu > Monticello > +Repository > squeaksource.com... MCSqueaksourceRepository location: 'http://squeaksource.com/ical' user: '' password: '' ==> open repository then errors "MCRepositoryError: Could not access http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for utf-8 encoding" In Chrome, opening http://www.squeaksource.com/ical then clicking <Versions> and the browser's View Page Source, I see... <?xml version="1.0" encoding="iso-8859-1"?> Googling: zinc iso-8859-1 finds... http://forum.world.st/Problem-using-Zinc-in-Pharo-4-Moose-5-1-td4825329.html but "ZnByteEncoder iso88591" errors with "KeyNotFound: key 'iso88591' not found in Dictionary" and inspecting "ZnByteEncoder byteTextConverters keys sorted" confirms this key is missing (@Sven, I'm curious why was this removed? ) Now https://en.wikipedia.org/wiki/ISO/IEC_8859-1 indicates IBM819 is an alias and " ZnByteEncoder newForEncoding: 'ibm819' " works okay So in MCHttpRepository>>#loadAllFileNames changing... queryAt: 'C' put: 'M;O=D' ; get. to... queryAt: 'C' put: 'M;O=D' . ZnDefaultCharacterEncoder value: (ZnByteEncoder newForEncoding: 'ibm819') during: [client get]. Then from Monticello opening the previously defined http://squeaksource.com/ical works!! Now I was hoping that reverting #loadAllFileNames and in Playground doing... converters := ZnByteEncoder byteTextConverters. converters at: 'iso-8859-1' put: (converters at: 'ibm819'). might alleviate the problem, but no luck. Anyone know a better way to deal with this that hardcoding the encoding into #loadAllFileNames? cheers -ben

March 15, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Esteban Lorenzano

sorry for coming late to this threadâ¦ hard week :) why we are trying to compile with cygwin? is there a problem with the mingw distro? I didnât have the time to update the README, sadly. But wellâ¦ following appveyor configuration should give you all you need to reproduce the build (thatâs what I did last time I built an environment). Esteban > On 15 Mar 2017, at 10:11, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be <mailto:philippe.back@highoctane.be> <philippe.back(a)gmail.com <mailto:philippe.back@gmail.com>>: > I made my own build here. > Not up to date with latest stuff but should work for the build process. > > https://ci.appveyor.com/project/philippeback/pharo-vm <https://ci.appveyor.com/project/philippeback/pharo-vm> > > It uses my forked repo and provided you set your own bintray env vars for API keys will publish there. > > Check all of the output of env vars and where/which in the appveyor console to see what gets used when when it comes to compilers and so on as there were various compiler versions involved at one point. > > Third party cache part is also worth checking. > > Still not able to build on my local box at the moment due to some tools discrepancies happening. > > My build artifacts are embarking too much at this point but allow you ro get the release, debug, and assert vms for windows. This helps when debugging as backtraces and so on are much more meaningful and one can use gdb more effectively to understand what is going on. > > Just keep the dlls and exes and you'll be fine. > > Ah good, thank you. > > > > HTH > > Phil > > Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> a Ã©crit : > > > 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>: > > > 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>: > > > 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > > > 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>>: > Hi Nicolai, > > If you look at appveyor.yml configuration on https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.appveyor.yml>, you will see that the pharo brand is not yet in the matrix. > > It's because builds are based on cygwin, but as I understood, some library used by some plugin required by pharo refuse to compile with cygwin. They appear to work with mingw32. > Cygwin provides headers for legacy directx, some distribution of mingw32 did in the past, but it does not seem the case anymore. > Using the directx headers from Microsoft SDK is a problem. They are not redistributable and can't be found anymore on the net (too old). We cannot seriously base the builds on something so fragile (both technically and legally) in the long term. > > Also, the 64 bits VM does only work with clang, and we don't have anything available as a 64bits Microsoft SDK... So pharo has to fix that too. > > In the interim, you should look at https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml <https://github.com/pharo-project/pharo-vm/blob/master/.appveyor.yml> and follow the scripts there. > > Ok, thank you. > > > I gave it a shot on sunday, because it was particularly rainy in Nantes, and I almost succeeded in compiling all the dependencies with cygwin. > Well, I mean with autotools cmake libtool pkg-config and I surely forget a few other niceties that some not so well informed programmers committed with the faith that it would make their life "easier". It certainly does not make mine simpler... > Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it seems that the workaround of Igor does not work anymore. > ssize_t, WTF??? > Maybe I'll be able to fix it tonight. Or tomorrow. In which case I'll publish the branch to see how far appveyor goes. > > > > So I solved the ssize_t problem by removing the hack from Igor which is not necessary anymore... > But got another problem soon after while building the tests... > There are trailing lines generated at end of tests/cairo-test-constructors.c that make the compilation fail: > > i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include/libpng16 -Wall -Wextra -Wmissing-declarations -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 -Wno-unused-but-set-variable -D_REENTRANT -m32 -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c -o cairo_test_suite-cairo-test-constructors.o `test -f 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c > cairo-test-constructors.c:1118:1: attention : la dÃ©finition de donnÃ©es n'a pas de type ni de classe de stockage > oning (); > ^ > cairo-test-constructors.c:1118:1: attention : type defaults to âintâ in declaration of âoningâ [-Wimplicit-int] > cairo-test-constructors.c:1119:5: attention : la dÃ©finition de donnÃ©es n'a pas de type ni de classe de stockage > _register_ft_show_glyphs_table (); > ^ > > And the file looks like it has obviously been overwritten, but not truncated !!! > > ... > extern void _register_multi_page (void); > extern void _register_fallback_resolution (void); > > void > _cairo_test_runner_register_tests (void) > { > _register_a1_bug (); > _register_a1_clip_paint (); > ... > _register_multi_page (); > _register_fallback_resolution (); > } > oning (); > _register_ft_show_glyphs_table (); > _register_ft_text_vertical_layout_type1 (); > _register_ft_text_vertical_layout_type3 (); > _register_ft_text_antialias_none (); > _register_ps_eps (); > _register_ps_features (); > _register_ps_surface_source (); > _register_svg_surface (); > _register_svg_clip (); > _register_svg_surface_source (); > _register_multi_page (); > _register_fallback_resolution (); > } > > This file is generated by a shell script test/make-cairo-test-constructors.sh > I can't find any reference of the bug, and upgrade to version 1.14.8 does not solve the issue. > So it will wait until tomorrow... > > > I got the build for windows with mingw nearly working. (it can not build some plugins, like SqueakSSL for windows, because the used wincrypt.h is different in the mingw distrubtion). > > I still have the problem, that there seems to be a preprocessing step , that should put the vm-version (and source timestamp) in the sqSCCSVersion.h > I got this working by running .travis_build.sh (with the options for arch/flavor/platform) But how is this done normally when you build a vm locally? > And how is this done for the pharo-vm we currently use? > > > > Nicolas > > > I hope that Esteban will find time to resolve all these problems and have pharo brand back on opensmalltalk-vm. I guess that any form of help is welcome. > > Nicolas > > > 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > I still have problems building a vm on windows. > can you give me some hints how to start ? > I cloned the recent pharo-vm project, > in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ > run > mvm > > But I got a couple of problems (mingw-32 compiler commands not found, I had to adjust the include path for finding directx header, missing variable replacement for git-versions). > So I may miss some important steps. > Is there a repository where I can clone the mingw environment used to build the win32-pharo-vm, the environment used on the build-server ? > > Thanks > Nicolai > > 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > > > 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > > > 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > >> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> >> >> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: >> Hi, >> >> I believe they're built from https://github.com/OpenSmalltalk/vm <https://github.com/OpenSmalltalk/vm> using travis and appveyor. On the gitbhub readme there are relevant links. All built artifacts are also kept on bintray for history. >> >> >> >> Thank you! > > no, they arenât :) > instead, they are built here: https://github.com/pharo-project/pharo-vm <https://github.com/pharo-project/pharo-vm> > > (README still not updated) > > what did changed ? I am not able to build the vm on windows anymore (something wrong with generating the generator.image, I'll now reset my local pharo-vm build directory and see if it works afterwards). > > see attached the stderr log : > > 'Errors in script loaded from u:\github\pharo-vm\scripts\LoadVMMaker.st' > [31mMessageNotUnderstood: receiver of "default:" is nil > [0mUndefinedObject(Object)>>doesNotUnderstand: #default: > BaseSoundSystem class>>initialize > MCMethodDefinition>>postloadOver: > > .... > > Are we still working with branch spur-64, or are we back on master ? > > > > Esteban > >> >> >> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> Where are the latest Pharo-spur-vms (32bit) are built? >> I don't see them on the build server, only the buildresults at >> http://files.pharo.org/vm/pharo-spur32/linux/ <http://files.pharo.org/vm/pharo-spur32/linux/> >> >> The latest builds on the buildserver are from the last year only. >> >> nicolai

March 15, 2017

Re: [Pharo-dev] Capitalized

by Torsten Bergmann

Hi, thanks for the feedback. So it depends on which definition we will follow... After investigating a little bit more I guess the current implementation is more valuable and should stay. For instance we can easily convert an ivar name into a class name with it: 'ellipseMorph' capitalized -> 'EllipseMorph' Also then this is in alignment with other dialects. Additionally: changing it would break too many things because it is often used in some #perform: based meta-magic and other (see SpecPreDebugWindow>>createNotifierPaneWidgets for an example) Sorry for the noise. I should upload a slice to Wikipedia + GitHub ;) Bye T. > Gesendet: Mittwoch, 15. MÃ¤rz 2017 um 14:30 Uhr > Von: "John Brant" <brant(a)refactoryworkers.com> > An: pharo-dev(a)lists.pharo.org > Betreff: Re: [Pharo-dev] Capitalized > > On 03/15/2017 05:33 AM, Torsten Bergmann wrote: > > According to https://en.wikipedia.org/wiki/Capitalization > > > > to "capitalize" is writing a word with its first letter as a capital letter (upper-case letter) > > AND THE REMAINING LETTERS IN LOWER CASE writing systems. > > > > So > > > > 'SOMETHING' capitalized > > > > currently returns "SOMETHING" in Pharo but should return "Something" according to the definition to end up with lowercase. > > If we fix this I guess we would also align Pharo with other languages, like C# for example [1]. > > That wouldn't be what I would expect. Here's what dictionary.com has for > capitalize: > > 1. to write or print in capital letters letters or > with an initial capital letter > > That definition doesn't say what happens with the rest of the letters. > > As for C#, isn't that someone's extension method for String and not a > Microsoft method? I don't see that method on Microsoft's current String > class documentation: > > https://msdn.microsoft.com/en-us/library/system.string(v=vs.110).aspx > > Also, the Uncapitalize method is inconsistent with the Capitalize > method. The Uncapitalize method changes only the first character and all > other characters are unchanged. However, the Capitalize method can > change all characters. > > Finally, Dolphin Smalltalk has an implementation that is similar to Pharo's: > > https://github.com/dolphinsmalltalk/Dolphin/blob/master/Core/Object%20Arts/… > > > John Brant > >

March 15, 2017

Re: [Pharo-dev] Capitalized

by Ben Coman

On Wed, Mar 15, 2017 at 6:33 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > According to https://en.wikipedia.org/wiki/Capitalization > > to "capitalize" is writing a word with its first letter as a capital > letter (upper-case letter) > AND THE REMAINING LETTERS IN LOWER CASE writing systems. > > So > > 'SOMETHING' capitalized > > currently returns "SOMETHING" in Pharo but should return "Something" > according to the definition to end up with lowercase. > I think it would be reasonable to expect... self assert: 'something' capitalized equals: 'SOMETHING' capitalized In ignorance of history, I'd call this a bug. Maybe not for "frozen" Pharo 6, but not needing a deprecation, just a fix. cheers -ben > If we fix this I guess we would also align Pharo with other languages, > like C# for example [1]. > > Could be easily changed by replacing "copy" with "asLowercase" in > #capitalized: > > capitalized > "Return a copy with the first letter capitalized" > | cap | > self isEmpty ifTrue: [ ^self copy ]. > cap := self asLowercase. > cap at: 1 put: (cap at: 1) asUppercase. > ^ cap > > Should we fix this? Do not know about any side effects... > > > Note: a) Squeak has the same issue > b) it fits for #uncapitalized, see [2] > c) Dont know about ANSI standard or any other ST dialect > > Thx > T. > > > [1] https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/ > CapitalizeTests.cs > [2] https://github.com/srkirkland/Inflector/blob/master/Inflector.Tests/ > UncapitalizeTests.cs > >

March 15, 2017