Re: Parrot 0.4.2 "GPW" Released!
I tried upgrading my gentoo box from parrot 0.4.0 to 0.4.2 by copying
the ebuild for 0.4.0 to 0.4.2 and emerging that.
It failed in the make install phase when it tried to install the
installable_ files to the live filesystem rather than to the install
target tree.
The ebuild calls make install with args that result in this invocation
of install_files.pl:
,
| /usr/bin/perl5.8.8 tools/dev/install_files.pl \
| --buildprefix=/portage/parrot-0.4.2/image/ \
| --prefix=/usr/lib/parrot-0.4.2 \
| --exec-prefix=/usr/lib/parrot-0.4.2 \
| --bindir=/usr/lib/parrot-0.4.2/bin \
| --libdir=/usr/lib/parrot-0.4.2/lib \
| --includedir=/usr/lib/parrot-0.4.2/include \
| --destdir= \
| --docdir=/usr/lib/parrot-0.4.2/share/doc/parrot \
| MANIFEST MANIFEST.generated
`
Running that with --dry-run=1 results in this at the end:
,
| ...
| runtime/parrot/library/parrotlib.pbc ->
/portage/parrot-0.4.2/image/usr/lib/parrot-0.4.2/lib/parrot/library/parrotlib.pbc
| runtime/parrot/library/pcre.pbc ->
/portage/parrot-0.4.2/image/usr/lib/parrot-0.4.2/lib/parrot/library/pcre.pbc
| installable_disassemble -> /usr/lib/parrot-0.4.2/bin/disassemble
| installable_disassemble.exe -> /usr/lib/parrot-0.4.2/bin/disassemble.exe
| ...
`
As you can see, the installable files are not prefixed by the value of
the --buildprefix as every other file in the MANIFEST.generated is.
The install_files.pl in 0.4.0 lacked @installable_exe and just
used @files. Just before pushing to @files, this is run:
,
| $dest = File::Spec->catdir($options{buildprefix}, $dest)
| if $options{buildprefix};
`
but that is not run before pushing to @installable_exe.
I see that --destdir was also added since 0.4.0, and changing the
ebuild to use DESTDIR=${D} instead of BUILDPREFIX=${D} does allow
the install to complete. But I wonder what the correct results
should be when both DESTDIR and BUILDPREFIX are specified to make?
-JimC
--
James H. Cloos, Jr. <[EMAIL PROTECTED]>
Re: Font used for raku welcome message
>>>>> "NG" == Norman Gaywood writes: NG> On Linux (various versions), if I ssh to another system and start the raku NG> REPL , I am greeted with: NG> Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.08. NG> Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d. U+1D411 is MATHEMATICAL BOLD CAPITAL R. The others are also part of the MATHEMATICAL BOLD block. It seems odd to use math bold for the software's and language's names rather than just outputting Rakudo and Raku in the greeting. I presume the goal was simply to embolden them. Norman, Search for a ttf font which supports the MATHEMATICAL BOLD unicode block. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: r27605 - docs/Perl6/Spec/S32-setting-library
lwall> + enum TrigBase is export ; Is Circles of much value? I can see Semicircles, since that would make the range (-1,1] or [-1,1). But a range of [0,1) or (0,1] seems *much* less useful. Or am I missing an obvious use case? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: Synopsis 02: Range objects
>>>>> "Michael" == Michael Zedeler writes: Michael> The Range 1.0001 .. 2.15 makes sense as an interval definition, but Michael> there can hardly be a useful list definition without defining a step Michael> size, at least, making it possible to use step sizes less than one. The obvious (default) choice for a step size would be the precision of the more precise of the two values. So 0.0001 in your example above. If they were specified in hex float syntax, such as 0x1.01P0 .. 0x3.123P0, then the (default) step should be 0x0.001P0 (which is the same as saying 1.00390625 .. 3.071044921875 with a step size of 0.000244140625). Michael> Complex .. Complex -> undef, exception or some other bad thing. Complex .. Complex should have a defined meaning in p6. A definition which is easy to compute would be the set of points contained by the square which has opposite corners at the two specified points. A better definition would be the set of points contained by the circle which has a diameter running between the two points. In both cases, of course, including the points actually on the 1-manifold. Either choice has the same meaning on the real axis as .. generates when given real args, and is useful for interval arithmetic. Something for which p6 is well suited. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: 1.23 becomes Rat (Re: Synopsis 02: Range objects)
>>>>> "Karl" == Karl Brodowsky writes: Karl> - or should there be a new numeric type similar to Rat that is always Karl> having powers of 10 as denominator (like BigDecimal in Java or Karl> LongDecimal for Ruby or decimal in C# or so)? If so, please use something compatable with ieee 754 decimal floats, so that they can be used when running on hardware which supports them. Even w/o such hardware, gcc (at least) has support for software emulation of _Decimal32 and _Decimal64 (and _Decimal128?). -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: Synopsis 02: Range objects
>>>>> "Michael" == Michael Zedeler writes: Michael> The Range 1.0001 .. 2.15 makes sense as an interval definition, but Michael> there can hardly be a useful list definition without defining a step Michael> size, at least, making it possible to use step sizes less than one. >> >> The obvious (default) choice for a step size would be the precision of >> the more precise of the two values. So 0.0001 in your example above. >> Michael> Well... maybe. How do you specify the intended precision, then? If I Michael> want the values from 1 to 2 with step size 0.01, I guess that writing Michael> 1.00 .. 2.00 The parser would have to note the precision as represented. On systems which have ieee-754 decimal floats that will be automatic (1., 1.0, 1.00, etc all have different representations in 754 decimal floats); it would not be a bad idea for Perl to keep track of that for all numerics. >> Complex .. Complex should have a defined meaning in p6. Michael> there is no natural ordering of complex numbers, and without Michael> some ordering, you may be able to decide what should be in the Michael> list to return, but not which order to use. [I'm merging stuff here.] Indeed, for interval arith it isn't ordering but inclusion which is relevant. If order is of value, it seems that it would have to be imposed. I can imagine that some people will want to zigzag from the point closest to (−∞,−∞) to the point closest to (+∞,+∞), whereas others might prefer to start at the point with the least r, sweeping θ through either [0°,360°) or (−π,π] or [−π,π) or Michael> I believe that anything we put into Perl 6 should have obvious Michael> use cases and fall natural into place in the domain that the Michael> construct in question belongs to. That is reasonable. Michael> but I must admit that I'd prefer if Complex .. Complex was left Michael> undefined in the Perl 6 core, leaving it up to anyone to Michael> specify it later. BTW, it I should have written a disc with diameter running between the two points rather than specifying an enclosing circle. It is true that when I think of p6, I think of more than core. But I would like support for interval arithmetic as ingrained in the p6 culture as, say, regexps. The set of problems which would benefit from widespread use of efficient interval techniques is significant. All that said, it may be the case that the .. syntax, though useful for specifying intervals, may not be preferred by those doing such coding. The may prefer a ± syntax, or something like ΤεΧ’s strech and shrink syntax for glue. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: Comments on S32/Numeric#Complex
> It would be reasonable for perl6 to have .arg to match .angle. [SIGH] ☹ Obviously, I meant to say: It would be reasonable for perl6 to have .arg to match¹ .abs. 1] or to complement, perhaps? ☺ -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: Comments on S32/Numeric#Complex
>>>>> "Doug" == Doug McNutt writes: >> Any ideas for a good name [for the angle]? Doug> In pre-computer times the angle was called the "argument". And that is still used. C99, as an example, calls the functions carg(3), cargf(3) and cargl(3), for operations on double complex, float complex and long double complex values, following its convention of using an f suffix for float, l suffix for long double and a c prefix for complex. It would be reasonable for perl6 to have .arg to match .angle. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: numerics, roles, and naming
>>>>> "DD" == Darren Duncan writes: Some tiny thoughts: DD> ... I would consider "Numeric" more broad, such as to include DD> anything that might conceivably be called a number, probably DD> user-defined, that isn't representable by a "complex". Is Numeric intended to have a guarantee of commutability? Ie, is it a ring? Or, put another way, would a Quaternion be a Numeric? DD> Or maybe better yet for completion sake, make "Gaussian" a role and DD> something like "Gaus" the type or something. Wasn’t his name Gauß? If so, then Gauß or Gauss, yes? In general, though, I agree with the thesis. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Ordering in \bbold{C}
Some time ago there was a thread disucssing numeric ordering issues; the fact that ℂ lacks an ordering was part of that discussion. A recent paper on arxiv proposes inflicting an ordering on ℂ using: ,< excerpt from http://arxiv.org/abs/1003.4906 > | | Given A = a₁ + i·a₂ and B = b₁ + i·b₂, then: | | A ≤ B if a₁ < b₁ || ( a₁ == b₁ && a₂ ≤ b₂ ) | A ≥ B if a₁ < b₁ || ( a₁ == b₁ && a₂ ≥ b₂ ) | ` I wonder whether having such an ordering available would be beneficial for Perl, or for coding in general? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: Ordering in \bbold{C}
>>>>> "M" == Minimiscience writes: M> Assuming that the last line should be "A ≥ B if a₁ > b₁ ...", Indeed, yes. Is there a worse off-by-one typo than '<' vs '>'? M> this is called lexicographic ordering, Oh. Yes. Of course. Obviosuly. I should have noticed that and do not know why I missed it. [SIGH]. I guess I must think of lex ordering mostly when thinking of /real/ polynomials How narrow-minded. ☺ M> Specifically, because -1 is a square in ℂ, ℂ being an ordered field M> would require that -1 > 0, which leads to a contradiction. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
