Hi,
I also think that adding the support would be very useful. However, I
would definitely avoid PCRE and backreference support. I think the
best solution would be to just add a basic and efficient NFA-based
implementation (the defacto original implementation for Unix). For
more information about t
Regardless whether things like casing should be supported, the problem is
that full Unicode support is required. APL is one of those languages where
you just can't get away with not supporting it. PCRE does support it, and
unfortunately I don't think POSIX regexp does.
Are there any any alternativ
Hi Elias,
I am generally in favour of supporting regular expressions in GNU
APL.
We should do that in a way that is compatible with the way in
which the most commonly used libraries
do that (even if they are lacking some features that more exot
Hi Xiao-Yong,
with
reinterpret_cast
I am getting (gcc 4.8) this:
Thread_context.cc:
In member function ‘void
Thread_context::print(std::ostream&) const’:
Thread_context.cc:73:42: error: invalid cast from type
‘pthread_t
An APL wrapper (⎕regexp[OP]) of a simple API like this would be great, (rune
means unicode)
https://9fans.github.io/plan9port/man/man3/regexp.html
One can build more APL functions out of these without much performance penalty.
On the other hand, if there is an DFA implementation provided by APL
Hi Xiao-Yong,
I can compile this:
<<
reinterpret_cast(
reinterpret_cast(thread))
Please let me know if it compiles on you box as well.
Best Regards,
Jürgen
On 09/20/2017 10:00 P
So you have a 32bit linux? Things got more complicated when you want memory
safety unfortunately.
POSIX basically tells us pthread_t can be anything, so if you really want to
print the content, perhaps the following would work without the compiler
complaining. (I think only char can be used fo
anyone who loves grep and hates perl (and i hope java too) can't be
all bad
using apl like syntax is goodaaa' ⎕REX['s'] 'bbb' what would monadic
⎕REX['s'] 'bbb' return?
On Wed, 20 Sep 2017 21:47:29 +0200
Juergen Sauermann wrote:
> Hi Elias,
>
> I am generally in favour of
reinterpret_cast works from smaller sizes to larger sizes.
So simply
reinterpret_cast(thread)
should work for both of our machines (size_t is uint64_t for me).
... until some pthread implementation decides to hand you a larger sized struct
for pthread_t.
> On Sep 20, 2017, at 3:26 PM, Ju
> On Sep 20, 2017, at 3:36 PM, Xiao-Yong Jin wrote:
>
> reinterpret_cast works from smaller sizes to larger sizes.
>
> So simply
> reinterpret_cast(thread)
Sorry, I meant
reinterpret_cast(thread)
>
> should work for both of our machines (size_t is uint64_t for me).
>
> ... until some p
Hi,
I do NOT want to access the content of the pthread, but I need
some identification that allows me
to distinguish the different threads that are running in parallel
(on different cores). So I dont care if pthread is
a pointer or an int as long as I
It so happens that 2 of my former colleagues from I.P.Sharp came visiting today
and we were chatting about this.
Ken was not in favour of making APL complicated. When I worked at IPSA my
office was next to Ken’s
and when someone suggested some form of addition to the language he would
usually a
On 21 September 2017 at 04:30, wrote:
anyone who loves grep and hates perl (and i hope java too) can't
> be all bad
>
> using apl like syntax is goodaaa' ⎕REX['s'] 'bbb' what would
> monadic ⎕REX['s'] 'bbb' return?
I don't think there is any reasonably monadic interpretation o
> On Sep 20, 2017, at 9:19 PM, Peter Teeson wrote:
>
> (These days performance can hardly be a compelling argument
> with multiple many-core CPU chips.)
This kind of argument for APL is exactly why Fortran is still alive and well.
14 matches
Mail list logo
