Recent changes to how the testsuite is run makes error messages from
expected failures to be printed out. That is not helpful.
Fixed.
Also, we've gone from 0 to 42 failing tests.
Also fixed. I was considering making Parser.HTML be a real html5
parser, by the way, but then I read
Recent changes to how the testsuite is run makes error messages from
expected failures to be printed out. That is not helpful.
Also, we've gone from 0 to 42 failing tests.
Well, that would work, except for this:
p-finish(t a='b'c='d''e'=\f\)-read();
([ /* 3 elements */
a: b,
c: d,
e: f
])
(3) Result: t a='b'c=d 'e'=\f\
Isn't the old syntax what Roxen uses to mix different quotes in the
same attribute value? I believe it's supposed to work like this:
foo attr=use ' here'use here'/
I do not really think that was ever an encouraged syntax? quote; has
always been preferably to my knowledge. It has been a
No, it was somewhat easy to fix so the attributes work as in HTML,
but now they no longer work as they used to.
I just called Hedda. He will take a look at it ASAP.
Is the exporter fixed yet?
Eep. That shouldn't be too hard to fix in Parser.HTML though?
Yes, I know, the question is if changing that is perhaps more
dangerous than changing how the quoting works.
Changing what? Hasn't it always been a syntax error? Just that the
parser doesn't actually report it?
Who would write something like that, and what would they intend it to
mean?
Also, I'm confused. Is
([ /* 3 elements */
a: b,
c: d,
e: f
])
supposed to be the old parser behaviour? Wouldn't that contradict
Jonas's claim that multiple quoted strings would get concatenated?
Or is it only if they use different quotes? Because in that case
there is _still_ no
I would like something that breaks down an html document to a
datastructure, preferable one with tools like searching.
Parser.HTML is created to allow RXML (or similar) parsing with as
little computron usage as possible. What I am using it for mostly is
breaking down random HTML documents for
Changing what? Hasn't it always been a syntax error? Just that the
parser doesn't actually report it?
No, Parser.HTML has always _explicitly_ allowed quoted attribute names
(it sets the allowed quotes to the same thing for both attribute
values and names).
I know this is fairly odd, but so
Sorry, I had an error in my it will now return mapping.
Actual example:
p-finish(t a='b''c'\d\e)-read();
([ /* 3 elements */
a: b,
c: c,
d: d
e: e
])
No, Parser.HTML has always _explicitly_ allowed quoted attribute
names
Where is this documented? Why would anyone use it?
(it sets the allowed quotes to the same thing for both attribute
values and names).
I know this is fairly odd, but so is the more-than-one-quoted-string
syntax.
t
I would like something that breaks down an html document to a
datastructure, preferable one with tools like searching.
Well, yes, a HTML tokenizer would be useful. HTML5 has a very readable
specification.
Parser.HTML is created to allow RXML (or similar) parsing with as
little computron usage as
Really? That doesn't even have matched quotes...
You are free to leave out the last endquote...
Do I understand correctly that the old parser allows quoted attributes
and multiple strings in attribute values, but does not allow multiple
attributes without whitespace in between or multiple strings in
attribute values _with_ whitespace in between?
So
t a=foo bar
would have two attributes a
Do I understand correctly that the old parser allows quoted attributes
and multiple strings in attribute values, but does not allow multiple
attributes without whitespace in between or multiple strings in
attribute values _with_ whitespace in between?
Yes. (it also allows quoted and multiple
The strings do not have to be quoted to be considered for
aggregation. Any string that does not contain non-quoted whitespaces
will do.
But is there any _point_ in aggregating a quoted string with a
non-quoted one? And, again, was such behaviour ever documented?
a=foobar='gazonk' would define
that is written shorter and less convoluted!
Indeed.
The actual example in the testsuite was more along the lines of
foo='This is a quotes string. it'''s using both types of quotes'
- This is a quoted string. It's using both types of quotes
I would prefer using entities, myself. And I think
Here's one of several real-world examples that I found from our CMS
(it's a bit tricky to grep after these constructs...):
#define quote(X) (replace((X)||, ', '\'\'))
[...]
var name='destname' type='string' size='40' default=' +
quote(sbobj-name(id)) + ' /
A sbobj-name() returning 'foo'
The actual example in the testsuite was more along the lines of
foo='This is a quotes string. it'''s using both types of quotes'
- This is a quoted string. It's using both types of quotes
Which is fine. That example does not aggregate quoted values with
non-quoted ones.
For any potential
Well, the quoted attribute thing seems to have been a red herring,
since it is actually clear how to interpret every such case:
If there is whitespace between the two quoted things, then the second
quoted thing is an attribute name. If there is no whitespace bwteeen
the two quoted things, then
And if the behaviour is not documented, it is undefined and could be
changed at any time. ;-)
No. That is not how it works. If the current behaviour might be in use
compatibility is not something that should be dropped without
consideration. _I_ think it's ugly as hell and should be dropped if
I think it was just following the same quotation methods allowed in
scripts. I'm not sure if any browser actually parsed the entities like
that, but they used to be way too nice on how they allowed things to
be written...
Or Parser.HTML5?
Well, yes, a HTML tokenizer would be useful. HTML5 has a very readable
specification.
So maybe it's time for a new tool.
Ironically enough it is about 10 times slower than ye olde Opera HTML5
parser at actually parsing html. :)
Yes, but I believe it was written to search for specific tags,
Fixed. The reason was that I skipped calling the initializers if there
wasn't any storage.
I now get this fatal in the testsuite (x86_64 with rtldebug):
Doing tests in testsuite (11311 tests)
Testing scoped variables 255:1...
Testing scoped variables 256:1 expecting a compilation error...
Testing scoped variables 16:17...
Testing scoped variables 17:16...
test 578, line 3250
Testing
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
The OS X manpage for ld mentions a -macosx_version_min option, are
we correctly applying that one? I'm assuming it needs to match the
number used for __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ for
things to work out
Actually, it seems like cc is already adding that option when it invokes
ld depending on the value of the environment values of
MAC_OS_X_VERSION_MIN_REQUIRED and MACOSX_DEPLOYMENT_TARGET.
Well, maybe, I misunderstood the docs, and MAC_OS_X_VERSION_MIN_REQUIRED is
set according to
Stephen R. van den Berg wrote:
I've reenabled socketpair_ultra in a few more cases (for systems where
UNIX_SOCKETS_WORKS_WITH_SHUTDOWN hasn't been set).
Is the recent MacOSX breakage a result of this capability not properly
being diagnosed in configure?
Found and (sort of) fixed this.
Summary
Therefore I disabled the MACOSX_DEPLOYMENT_TARGET=10.3 macro. Not
sure what negative impact this has. People with MacOSX experience,
please look into it (I merely tested it on my Leopard MacBook).
We're still building on 10.4 and 10.5 in various combinations of
PPC32, x86 and x86_64 and I'd
to zoom in on the
testsuite problems.
assign a more recent version number to the environment variable? I
don't see a problem with discontinuing support for 10.3 specifically
if that helps.
Well, on my Leopard MacBook, setting it to 10.4 exhibits the same
problem, setting it to 10.5 solves
So if I understand correctly the value of EOPNOTSUPP changed between
10.4 and 10.5. Is there no way to detect the correct value at
runtime? It seems like coding one or the other value into the
binary will prevent it from working on the other OS version...
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
So if I understand correctly the value of EOPNOTSUPP changed between
10.4 and 10.5. Is there no way to detect the correct value at
runtime? It seems like coding one or the other value into the
binary will prevent it
...but AvailabilityMacros.h indicates that it should already be done
through MACOSX_DEPLOYMENT_TARGET. Hmm, perhaps the latter isn't set in
enough places during Pike builds?
Dan Nelson wrote:
In the last episode (Feb 19), Stephen R. van den Berg said:
With respect to the FreeBSD testsuite failures, I suspect they're the
result of a failing write_oob in which the send() system call returns an
ECONNRESET for some reason. It seems a bit silly though to insert
I
Jonas Walld?n @ Pike developers forum wrote:
Looks from /usr/include/sys/cdefs.h that we need to set
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ to something lower than
1050 (for 10.5) to avoid __DARWIN_UNIX03.
Actually, we *want* __DARWIN_UNIX03 to be set to 1.
Quoting from sys/errno.h:
#if
What does it mean that the value is only discrete when compiling
__DARWIN_UNIX03? What is the definition when __DARWIN_UNIX03 is not
true? If the value changed to 102 in 10.5, then it makes sense to
compile in the constant 102 only if you are going to support 10.5 and
newer exclusively, which is
Actually, we *want* __DARWIN_UNIX03 to be set to 1.
At least on a MacOSX Leopard Macbook we do, because that one returns
102 from the kernel incase of a not-supported error.
But errno.h says there is a libc stub that converts it back to 45 if
it's not set.
Anyway, I don't ask for builds
Googling some on the code snippet you showed us, I found the other
half:
#if !__DARWIN_UNIX03 !defined(KERNEL)
/*
* This is the same for binary and source copmpatability, unless compiling
* the kernel itself, or compiling __DARWIN_UNIX03; if compiling for the
* kernel, the correct value will
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Googling some on the code snippet you showed us, I found the other
half:
* source, the kernel return value will be converted by a stub in libc, and
* if compiling source with __DARWIN_UNIX03, the conversion in libc is
In the last episode (Feb 20), Stephen R. van den Berg said:
Stephen R. van den Berg wrote:
I've reenabled socketpair_ultra in a few more cases (for systems where
UNIX_SOCKETS_WORKS_WITH_SHUTDOWN hasn't been set).
Is the recent MacOSX breakage a result of this capability not properly
being
Summary of the changes:
- Closing a socket one-way, results in errors when still trying to get OOB
data from it. I.e. the OS signals an error because it knows that OOB
data cannot be sent anymore.
Is this a kernel bug? Shutting down the socket for writes should still
allow reads to
I've reenabled socketpair_ultra in a few more cases (for systems where
UNIX_SOCKETS_WORKS_WITH_SHUTDOWN hasn't been set).
Is the recent MacOSX breakage a result of this capability not properly
being diagnosed in configure?
--
Sincerely,
Stephen R. van den Berg.
Real Life? I've played
(not to worry, the cruft is still there
for AmigaOS fans).
The testsuite now works on Linux and Solaris.
I don't have any other way to test it really except by checking it in.
I'll be doing so in a few minutes. Please review the changes.
N.B. The changes in socktest are necessary because the previous
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
The testsuite now works on Linux and Solaris.
I don't have any other way to test it really except by checking it in.
I'll be doing so in a few minutes. Please review the changes.
Ok, the game is afoot.
I would appreciate some last
Henrik stated:
Fixed persistent typo in symbol
UNIX_SOCKETS_WORKS_WITH_SHUTDOWN: WORK == WORKS
Not that it is such a big deal, but, UNIX Sockets is plural, so
in proper English the verb should be work, not works.
Or am I misinterpreting the intention?
--
Sincerely,
Stephen R. van den
Peter Bortas @ Pike developers forum wrote:
Do I have enough quota on the git-pike Solaris account to try and hunt
this one down?
You are limited to 75 OS threads in that instance, but other than
that there aren't any limits you should hit besides what the
underlaying machine offers in
Sure, installed.
51 matches
Mail list logo
