Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image
> On 30 Jun 2016, at 05:09, Ben Coman wrote: > > On Tue, Jun 28, 2016 at 6:04 PM, Max Leske wrote: >> Hi, >> >> Opening the same image twice works fine as long as no writes to the .changes >> file occur. When both images write to the .changes file however it will be >> broken for both because the offsets for the changes are wrong. This can lead >> to lost data and predominantly to invalid method source code, which is a >> pain with Monticello. >> >> I suggest that we implement a kind of lock mechanism to ensure that only one >> image (the first one opened) can write to the .changes file. >> >> >> I’ve opened an issue for Pharo here: >> https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to-a-single-image >> >> >> Cheers, >> Max > > I just learnt something quite surprising that is probably important to > be aware of... "Locks given by fcntl are not associated with the > file-descriptor or open-file table entries. Instead, they are bound to > the process itself. For example, a process has multiple open file > descriptors for a particular file and gets a read/write lock using any > one of these descriptors. Now closing any of these file descriptors > will release the lock, the process holds on the file. The descriptor > that was used to acquire the lock in the first place might still be > open, but the process will loose its lock. So, it does not require an > explicit unlock or a close ONLY on the descriptor that was used to > acquire the lock in fcntl call. Doing unlock or close on any of the > open file descriptors will release the lock owned by the process on > the particular file." > > https://loonytek.com/2015/01/15/advisory-file-locking-differences-between-posix-and-bsd-locks/ > > cheers -ben > Which would solve the problem of a crashed image not cleaning up its lock. Thanks for sharing Ben.
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/60127 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 59ad9e: 60127
Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 59ad9eafc76334d06cdba97d22a8ce2c38010146 https://github.com/pharo-project/pharo-core/commit/59ad9eafc76334d06cdba97d22a8ce2c38010146 Author: Jenkins Build Server Date: 2016-06-30 (Thu, 30 Jun 2016) Changed paths: M Kernel-Tests.package/RecursionStopperTest.class/README.md M Kernel-Tests.package/RecursionStopperTest.class/definition.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/mixedMethod.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/recursion.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/setUp.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/tearDown.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/testMixedMethod.st M Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/testNoRecursion.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/testThreadSafe.st M Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/testWithRecursion.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/threadSafe.st M Kernel.package/Halt.class/class/halting/once.st M Kernel.package/Halt.class/class/once-reset/resetHaltOnCount.st M Kernel.package/Halt.class/class/once-reset/resetHaltOnce.st M Kernel.package/RecursionStopper.class/README.md R Kernel.package/RecursionStopper.class/class/api/check.st A Kernel.package/RecursionStopper.class/class/api/default.st M Kernel.package/RecursionStopper.class/class/api/during_.st R Kernel.package/RecursionStopper.class/class/api/off.st R Kernel.package/RecursionStopper.class/class/api/on.st M Kernel.package/RecursionStopper.class/definition.st A Kernel.package/RecursionStopper.class/instance/as yet unclassified/initialize.st A Kernel.package/RecursionStopper.class/instance/as yet unclassified/stopMethod_during_.st A Reflectivity-Tools.package/FlagIconStyler.class/README.md A Reflectivity-Tools.package/FlagIconStyler.class/definition.st A Reflectivity-Tools.package/FlagIconStyler.class/instance/defaults/highlightColor.st A Reflectivity-Tools.package/FlagIconStyler.class/instance/defaults/iconFor_.st A Reflectivity-Tools.package/FlagIconStyler.class/instance/defaults/iconLabel_.st A Reflectivity-Tools.package/FlagIconStyler.class/instance/testing/shouldStyleNode_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60126.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60127.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60126.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60127.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 60127 18628 can not put haltOnce in RBScanner methods https://pharo.fogbugz.com/f/cases/18628 18644 IconStyler for "self flag:" https://pharo.fogbugz.com/f/cases/18644 http://files.pharo.org/image/60/60127.zip
Re: [Pharo-dev] Subscription Form to FogBugz
it's fixed! thanks bye! Tomas 2016-06-30 1:15 GMT-04:00 Esteban Lorenzano : > yeah, no… there was a problem with credentials in app. > can you try again? > > thanks, > Esteban > > > On 29 Jun 2016, at 23:56, Ben Coman wrote: > > > > On Thu, Jun 30, 2016 at 2:40 AM, Tomas Saez Binelli > > wrote: > >> Hi everybody! > >> > >> I was trying to create an account on Fogbugz during a Sprint using the > link > >> posted here: > >> > >> https://pharo.fogbugz.com/ > >> > >> But after filling the form and submiting it, i received the following > >> message: > >> > >> "Incorrect password or username" > >> > >> This is a little bit strange because i was not able to finish the > >> registration and create an account. > >> > >> Sending this email to make the error public. > >> > >> > >> Bye! > >> Tomas > >> > > > > Thanks for the report Tomas. I think I've seen this a long time ago, > > maybe your account was created but something went wrong with setting > > the password. As a work around, see if you can find a password reset > > button. > > > > cheers -ben > > > > >
[Pharo-dev] [pharo-project/pharo-core] b51a9d: 60128
Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 https://github.com/pharo-project/pharo-core/commit/b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 Author: Jenkins Build Server Date: 2016-06-30 (Thu, 30 Jun 2016) Changed paths: M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version210_.st M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version29_.st M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version315_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version323_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline34_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/development_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version417_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60127.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60128.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60127.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60128.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 60128 Moose http://files.pharo.org/image/60/60128.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/60128 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] [Vm-dev] Re: [ANN] Ephemeron Support is Ready
On 06/30/2016 03:17 AM, Marcus Denker wrote:
I added a new Code-Critic rule "RBDeadBlockRule", with
initialize
super initialize.
self matcher
matches: '`{:node | node isBlock and: [node parent isSequence
and: [ node isLastStatementInBlock not ]]}'
do: [ :node :answer | node ]
Instead of "node parent isSequence and: [ node isLastStatementInBlock
not ]", you can use "node isUsed not".
John Brant
Re: [Pharo-dev] Subscription Form to FogBugz
Thanks Tomas! Alexandre > On Jun 30, 2016, at 8:08 AM, Tomas Saez Binelli > wrote: > > it's fixed! > thanks > > bye! Tomas > > 2016-06-30 1:15 GMT-04:00 Esteban Lorenzano : > yeah, no… there was a problem with credentials in app. > can you try again? > > thanks, > Esteban > > > On 29 Jun 2016, at 23:56, Ben Coman wrote: > > > > On Thu, Jun 30, 2016 at 2:40 AM, Tomas Saez Binelli > > wrote: > >> Hi everybody! > >> > >> I was trying to create an account on Fogbugz during a Sprint using the link > >> posted here: > >> > >> https://pharo.fogbugz.com/ > >> > >> But after filling the form and submiting it, i received the following > >> message: > >> > >> "Incorrect password or username" > >> > >> This is a little bit strange because i was not able to finish the > >> registration and create an account. > >> > >> Sending this email to make the error public. > >> > >> > >> Bye! > >> Tomas > >> > > > > Thanks for the report Tomas. I think I've seen this a long time ago, > > maybe your account was created but something went wrong with setting > > the password. As a work around, see if you can find a password reset > > button. > > > > cheers -ben > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Vm-dev] Re: [ANN] Ephemeron Support is Ready
> On 30 Jun 2016, at 14:57, John Brant wrote:
>
> On 06/30/2016 03:17 AM, Marcus Denker wrote:
>
>> I added a new Code-Critic rule "RBDeadBlockRule", with
>>
>> initialize
>> super initialize.
>> self matcher
>> matches: '`{:node | node isBlock and: [node parent isSequence
>> and: [ node isLastStatementInBlock not ]]}'
>> do: [ :node :answer | node ]
>
> Instead of "node parent isSequence and: [ node isLastStatementInBlock not ]",
> you can use "node isUsed not".
>
Nice! I have submitted a patch to change it.
Marcus
Re: [Pharo-dev] [pharo-project/pharo-core] b51a9d: 60128
what were the changes? Stef Le 30/6/16 à 14:49, GitHub a écrit : Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 https://github.com/pharo-project/pharo-core/commit/b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 Author: Jenkins Build Server Date: 2016-06-30 (Thu, 30 Jun 2016) Changed paths: M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version210_.st M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version29_.st M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version315_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version323_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline34_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/development_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version417_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60127.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60128.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60127.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60128.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 60128 Moose http://files.pharo.org/image/60/60128.zip
Re: [Pharo-dev] [pharo-project/pharo-core] b51a9d: 60128
looks like something went wrong > On 30 Jun 2016, at 19:50, stepharo wrote: > > what were the changes? > > > Stef > > > Le 30/6/16 à 14:49, GitHub a écrit : >> Branch: refs/heads/6.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 >> >> https://github.com/pharo-project/pharo-core/commit/b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 >> Author: Jenkins Build Server >> Date: 2016-06-30 (Thu, 30 Jun 2016) >> >> Changed paths: >> M >> ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic >> versions/stable_.st >> A >> ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version210_.st >> M >> ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version29_.st >> M >> ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic >> versions/stable_.st >> A >> ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st >> M >> ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic >> versions/stable_.st >> A >> ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version315_.st >> M >> ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic >> versions/stable_.st >> A >> ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st >> M >> ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic >> versions/stable_.st >> M >> ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st >> A >> ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version323_.st >> A >> ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline34_.st >> M >> ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic >> versions/development_.st >> M >> ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic >> versions/stable_.st >> A >> ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version417_.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - >> scripts/script60127.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - >> scripts/script60128.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - >> updates/update60127.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - >> updates/update60128.st >> M >> ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> >> Log Message: >> --- >> 60128 >> Moose >> >> http://files.pharo.org/image/60/60128.zip >> >> > >
Re: [Pharo-dev] Percent-encoding problem
Hi Sven, Thanks for the answer. I needed to overwrite encodeQuery:on: and printQueryOn: for my use case. See attachment. I think being able to optionally configure the characterEncoder would be useful for ZnUrl in general. ZnUrl would then need to pass the characterEncoder to all calls to ZnResourceMetaUtils, not only to some like now. That would also be more consistent. Having ZnResourceMetaUtils use ZnUTF8Encoder by default seems a bit dangerous also. What do you think? Thanks for Zinc! Cheers, Bernhard ZnEncodingUrl.st Description: Binary data > Am 28.06.2016 um 22:16 schrieb Sven Van Caekenberghe : > > Bernard, > > I understand the issue, but this is not so easy to fix. > > I must start by saying that encoding a (part of) a URL with anything but > UTF-8 is wrong (how would the receiver know, unless you have a mutual > external agreement). So I guess you must be using some old web service. > > The solution is to make your own ZnUrl subclass and overwrite #encodePath:on: > > Then you just instanciate your subclass from elementary parts (no encoding) > and pass it to ZnClient>>#url: as an object, not a string. > > Mind you, I haven't tried this yet. > > Sven > >> On 28 Jun 2016, at 20:26, Bernhard Pieber wrote: >> >> I have a web service where I have to use a URL with percent-encoded (URL >> encoded) special characters – German Umlauts – but not using UTF8 but >> ISO-8859-1. I have been given the following table for the „correct“ >> encodings: http://www.degraeve.com/reference/urlencoding.php >> >> I found out that I can use the following to get the encoding I need (%FC): >> ZnPercentEncoder new >> characterEncoder: (ZnCharacterEncoder newForEncoding: 'iso-8859-1'); >> encode: 'ü'. >> >> However, when I try to use the encoded URL with ZnClient >> ZnClient new >> url: 'http://example.com/%FC'; >> get. >> >> I get a ZnUTF8Encoder>>errorIllegalLeadingByte (Illegal leading byte for >> utf-8 encoding). >> >> Any help is greatly appreciated. >> >> Cheers, >> Bernhard >> >> >> >> > >
Re: [Pharo-dev] Having comments for pragma?
Hi,
> On Jun 27, 2016, at 7:55 PM, Eliot Miranda wrote:
>
> Hi Doru,
>
> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba wrote:
> Hi Eliot,
>
> I agree with most things you say (except the conclusion :)), and I think that
> we are talking about complementary issues.
>
> As I mentioned before, there already is a need to distinguish between a plain
> selector and one that is associated with pragmas. This is what you find in
> PragmaType in Spotter and Inspector. This is a kind of meta-object and having
> it adds value. I can search for pragmas “type” (we can also call it a
> PragmaSelector), and I can distinguish between all occurrences of a pragma
> “type” and its utilization in computation. But, the current implementation of
> PragmaType is a mere pseudo-meta-object, given that it has no casual
> connection to the runtime.
>
> What we know from Smalltalk is that the analysis model does not have to
> differ from the runtime one. The consequence is that every time we do see a
> difference, we should investigate because we might uncover a hidden need
> opportunity.
>
> I know the VW model, and indeed, we could have something like:
>
> MyConcept class>>myPragmaDefinition
> “a comment about the pragma"
>
>
> However, this only deals with the definition of the pragma type not with the
> internal representation. There could still well be an object that
> encapsulates both the selector and the comment. And that object would also
> allow us to build tools around it. We could call it a PragmaType,
> PragmaDefinition, or even PragmaSelector. And we could get the Pragma to
> point to this type either through an inst var or through a query (I would
> probably prefer an instvar).
>
> Well, there already /is/ a meta-object called Pragma, and it gets
> instantiated when one accesses the compiled method via pragmas:
>
> (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas
> collect: [:ea| {ea. ea class}] {{ . Pragma} . { type: 'int *'> . Pragma}}
Yes I know :). An instance of Pragma denotes an concrete annotation of a
method. I now would like a meta-object that describes all Pragma instances
having the same selector. For example, the protocol on the class side of the
Pragma class is actually a query protocol that is better suited for the
instance side of a PragmaDescription meta-object. For example:
Pragma class>>allNamed: aSymbol in: aClass
would become
PragmaDescription>>pragmasIn: aClass
and you would use it like:
(PragmaDescription named: aSymbol) pragmasIn: aClass
Creating an instance of PragmaDescription would imply searching the image for
the definition. I would also like to have a Flyweight pool per
environment such that we always get only one instance of a PragmaDefinition per
selector (like it happens with Symbols).
> So we could add the information you want to Pragma, and have it be lazy.
It does not quite belong to the Pragma. A comment is common to all Pragma
instances, and having it duplicated at the instance level is less elegant.
But, looking for the users (all senders of the pragma selector - the methods
that use the annotation) of a Pragma would be even less inconvenient to have on
the instance side of Pragma.
> The Pragma could go search for the defining class-side pragma methods and use
> the parser to extract the comment(s) when asked. Hence simple access to
> pragmas, interested only in the selectors for applying, wouldn't have their
> performance be impacted.
The design sketched above would require no runtime penalty for a Pragma
instance. All code that works now would work identically afterwards. We would
only have one selector in Pragma to get the corresponding description:
Pragma>>description
^ PragmaDescription named: self selector
Alternatively, we could modify the compilation to associate the
PragmaDescription in an inst var of a Pragma instance. So,
CompiledMethod>>pragmas would always return instances of Pragmas with a
PragmaDefinition inst var.
I think I would start with the lazy lookup first, and this would disturb
nothing from the current behavior.
> I think that this proposition does not remove from the simplicity of the
> implementation at all, but allows the new needs to be accommodated nicely.
> The alternative is to not do anything, in which case we will continue to have
> an analysis-only-pseudo-meta-object which is not nice at all. I do not think
> we should jump on this lightly, but I do think we should have a critical look
> and evaluate the options.
>
> This pseudo-meta-object (Pragma) can sty ill be causally connected, in the
> same way that a MethodReference can be causally connected. The causation is
> things like "remove", "recompile", but that's dubious. It's essentially a
> read-only relationship; one wants to be able to locate the method from the
> pragma, but changing the method from the pragma isn't necessarily a good
> idea
Re: [Pharo-dev] Percent-encoding problem
Bernhard, > On 30 Jun 2016, at 21:12, Bernhard Pieber wrote: > > Hi Sven, > > Thanks for the answer. I needed to overwrite encodeQuery:on: and > printQueryOn: for my use case. See attachment. I think being able to > optionally configure the characterEncoder would be useful for ZnUrl in > general. ZnUrl would then need to pass the characterEncoder to all calls to > ZnResourceMetaUtils, not only to some like now. That would also be more > consistent. Having ZnResourceMetaUtils use ZnUTF8Encoder by default seems a > bit dangerous also. What do you think? Like I said, IMHO there is no need for this flexibility, UTF-8 is the standard/default, it makes no sense to use another one, doing so is an error. https://en.wikipedia.org/wiki/Percent-encoding#Current_standard https://tools.ietf.org/html/rfc3986 (which obsoletes 3 older ones) Unless you can point me to some still relevant RFC that says otherwise, I am afraid things will stay as they are. But it is good that you were able to deal with your requirement - your code might be useful for others. Sven > Thanks for Zinc! > > Cheers, > Bernhard > > >> Am 28.06.2016 um 22:16 schrieb Sven Van Caekenberghe : >> >> Bernard, >> >> I understand the issue, but this is not so easy to fix. >> >> I must start by saying that encoding a (part of) a URL with anything but >> UTF-8 is wrong (how would the receiver know, unless you have a mutual >> external agreement). So I guess you must be using some old web service. >> >> The solution is to make your own ZnUrl subclass and overwrite #encodePath:on: >> >> Then you just instanciate your subclass from elementary parts (no encoding) >> and pass it to ZnClient>>#url: as an object, not a string. >> >> Mind you, I haven't tried this yet. >> >> Sven >> >>> On 28 Jun 2016, at 20:26, Bernhard Pieber wrote: >>> >>> I have a web service where I have to use a URL with percent-encoded (URL >>> encoded) special characters – German Umlauts – but not using UTF8 but >>> ISO-8859-1. I have been given the following table for the „correct“ >>> encodings: http://www.degraeve.com/reference/urlencoding.php >>> >>> I found out that I can use the following to get the encoding I need (%FC): >>> ZnPercentEncoder new >>> characterEncoder: (ZnCharacterEncoder newForEncoding: 'iso-8859-1'); >>> encode: 'ü'. >>> >>> However, when I try to use the encoded URL with ZnClient >>> ZnClient new >>> url: 'http://example.com/%FC'; >>> get. >>> >>> I get a ZnUTF8Encoder>>errorIllegalLeadingByte (Illegal leading byte for >>> utf-8 encoding). >>> >>> Any help is greatly appreciated. >>> >>> Cheers, >>> Bernhard >>> >>> >>> >>> >> >> >
