date:20190220

Re: [Oorexx-devel] Also, CMakeList.txt same thing or me, tried to override?

2019-02-20 Thread Jason Martin


I meant dupe's or was I not seeing a level of indentation of if's.

I patched once just to remove and was suprised to see gnu++11 come back 
on next compile.


Also Haiku cmake was 3.9.5 but it still picked gnu++11.

Could be Haiku cmake pkg though.



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Fwd: [Oorexx-svn] SF.net SVN: oorexx-code-0:[11792] main/trunk/common/platform/unix/ SysSemaphore.cpp

2019-02-20 Thread Rick McGuire

I'm thinking this should just be #ifdef HAVE_SCHED_H rather than listing
the platforms. That's the header file sched_param is defined in, so
probably one of the other linux header files is including it already. It
should be benign to include it here if the platform has it.

Rick

-- Forwarded message -
From: erich_st--- via Oorexx-svn 
Date: Wed, Feb 20, 2019 at 1:45 PM
Subject: [Oorexx-svn] SF.net SVN: oorexx-code-0:[11792]
main/trunk/common/platform/unix/ SysSemaphore.cpp
To: 
Cc: 


Revision: 11792
  http://sourceforge.net/p/oorexx/code-0/11792
Author:   erich_st
Date: 2019-02-20 18:45:03 + (Wed, 20 Feb 2019)
Log Message:
---
fix typo

Modified Paths:
--
main/trunk/common/platform/unix/SysSemaphore.cpp

Modified: main/trunk/common/platform/unix/SysSemaphore.cpp
===
--- main/trunk/common/platform/unix/SysSemaphore.cpp2019-02-20 17:15:16
UTC (rev 11791)
+++ main/trunk/common/platform/unix/SysSemaphore.cpp2019-02-20 18:45:03
UTC (rev 11792)
@@ -56,7 +56,7 @@
 #include 
 #endif

-#if #if defined(OPSYS_SUN) || defined(__HAIKU__)
+#if defined(OPSYS_SUN) || defined(__HAIKU__)
 #include 
 #endif




___
Oorexx-svn mailing list
oorexx-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-svn
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Haiku now at full speed.

2019-02-20 Thread Erich Steinböck

>
> As soon I find all the things to fix
>  I will email  the svn diff report with some suggested modifications
>
Sounds great - waiting for the patch
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Also, CMakeList.txt same thing or me, tried to override?

2019-02-20 Thread Erich Steinböck

>
> Also, CMakeList.txt same thing or me, tried to override
>

Jason, I have no idea what this sentence means, but I've removed the
duplicated lines with revision revision [r11793]
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Haiku now at full speed.

2019-02-20 Thread Enrico Sorichetti via Oorexx-devel

The main problem is that the logic for header inclusion is seriously flawed …

The test should be on the availability of features features 
( HEADERS, FUNCTIONS, LIBRARIES)
Not on the system name (*)

Working on it
 As soon I find all the things to fix 
 I will email  the svn diff report with some suggested modifications


I did point them out
And again … the test should not be on the system name 
In my private ooRexx development copy 
I do not care about the system name …
In the CMakeLists I run a compilation of

#include 
int main()
{
charPath[1000];
char   *dPath = Path;
struct  stat file;
lstat64( dPath, &file);
return (0);
}

And if it fails I set the flag

E

(*)
The only instance where it is needed, because on the different prototype 
definition
#if defined(FREEBSD) || defined(OPENBSD)
return context->WholeNumberToObject((wholenumber_t)setpgrp(0, 0));
#else
return context->WholeNumberToObject((wholenumber_t)setpgrp());
#endif


> On 20 Feb 2019, at 19:35, Jason Martin  wrote:
> 
> This is not all the HAIKU patches but I looked at what I had to do to fix 
> OpenIndiana build.
> 
> GCC or OpenIndiana knew I needed 
> 
> 
> Someone pointed them out with my first patches.
> 
> Regina Rexx get most all right here, including enviroment and Address 
> statements.
> 
> But it is C and ooRexx would be better on Haiku. (C++ OS and C++ GUI)
> 
> OpenBSD ok before the 5.0.0 release you be extra GREAT too!
> 
> The more OSes the better the code.
> 
> 
> 
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Haiku now at full speed.

2019-02-20 Thread Jason Martin

This is not all the HAIKU patches but I looked at what I had to do to 
fix OpenIndiana build.


GCC or OpenIndiana knew I needed 

For some reason OpenIndiana complained when I did first build but Haiku 
did not.


I compiled latest on OpenIndiana with verbose on gmake build &> 
what_we_do_here.txt


Then Haiku make &> what_we_not_doing_here.txt

Compared what_we_do_here.txt with what_we_not_doing_here.txt

There are some more patches for Haiku related to stat64 file64 around 
_APPLE_ defines


Someone pointed them out with my first patches.

Regina Rexx get most all right here, including enviroment and Address 
statements.


But it is C and ooRexx would be better on Haiku. (C++ OS and C++ GUI)

OpenBSD ok before the 5.0.0 release you be extra GREAT too!

The more OSes the better the code.







___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Haiku now at full speed.

2019-02-20 Thread Erich Steinböck

>
> +#if defined(OPSYS_SUN) || defined(__HAIKU__)
>
this patch speeds things 6 fold
>
fixed with latest commit
So it would compile fine without this include, but with the include speed
improves six times?
Why is that? And: how did you figure this out?

Still do not have enviroment
>
Is this a Rexx-related issue or a quirk with Haiku?
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad loop counter on do...over ?

2019-02-20 Thread Gil Barmwater


Just another couple of points:

1) the ~supplier message is not needed;  ooRexx will "supply" it

2) in the case of relation collections, the [] method will return the 
first item with the specified index so relation collections with 
duplicate indices would need different handling (thanks Rony for 
pointing that out to me off-list)


Gil

On 2/20/2019 9:18 AM, Gil Barmwater wrote:


I think we are on the right track but it needs a little tweaking:

t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
sayt~class":"

dowithindexiitemoovert
say"#"i":"pp(o)
end
say

say"--- the desired output:"
i=1
dowithindexidxitemoovert
say"#"i":"pp(idx) "->"pp(o)
i=i+1
end
say

say"--- how about this?"
dowithindexiitemidxovert~allindexes~supplier
say"#"i":"pp(idx) "->"pp(t[idx])
end
say

::routinepp
return"["arg(1)"]"

Gil B

---

On 2/20/2019 8:06 AM, Rony G. Flatscher wrote:

On 20.02.2019 07:06, Erich Steinböck wrote:


number a do with  over a table where the indices are not
numbers, or over a set or bag

Use
do with index i item j over c~allItems


This is *not* the same collection as "c", but an array of all of the 
items in the "c" MapCollection! The important information of which 
index is associated with which item gets lost.


The "do with...over" is meant to iterate over a supplier which is 
especially important for non-orderable collections.


In the case of Map/SetCollections the index object is as important as 
the item object, such that it cannot be forgone. (The supplier is the 
only means for Map/SetCollections to get all index-item-pairs, cf. 
e.g. for .Relation collections.)


---

One may be inclined to think that "do with...over" is fine for 
Orderable collections as array collections demonstrate:


a=("a","z","b")
say a~class":"
do with index i item o over a
 say "#" i":" pp(o)
end
say

l=.list~of("a","y","b")
say l~class":"
do with index i item o over l
 say "#" i":" pp(o)
end
say

::routine pp
   return "["arg(1)"]"
---

G:\test\oorexx\201902doover>test_do_over.rex
The Array class:
# 1: [a]
# 2: [z]
# 3: [b]

The List class:
# 0: [a]
# 1: [y]
# 2: [b]

However the index value starting out with 0 in the List collection 
case! The expected output in the case of the List class probably 
would have been:


The List class:
# 1: [a]
# 2: [y]
# 3: [b]

However, as one can see the List does not have a numeric index that 
start with 1, like it is the case with Array collections.


In the case of an Orderable collection only the "allitems" array will 
allow for using the index for numbering, starting with one (because 
an array always starts with 1):


l=.list~of("a","y","b")
say l~class":"
do with index i item o over l~allItems
 say "#" i":" pp(o)
end
say

::routine pp
   return "["arg(1)"]"
---

G:\test\oorexx\201902doover>test_do_over.rex
The List class:
# 1: [a]
# 2: [y]
# 3: [b]

=

Using allItems or allIndexes would not help in the case of 
Map/SetCollections, where the index object is as important as the 
item object.


Example with a Table collection:

t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
say t~class":"

do with index i item o over t
 say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over t~allItems
 say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over t~allIndexes
 say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over t
 say "#" i":" pp(idx) "->" pp(o)
 i=i+1
end
say

::routine pp
   return "["arg(1)"]"

Yielding:

The Table class:
# berta: [female]
# caesar: [male]
# adam: [male]

--- now with t~allItems:
# 1: [female]
# 2: [male]
# 3: [male]

--- now with t~allIndexes:
# 1: [berta]
# 2: [caesar]
# 3: [adam]

--- the desired output:
# 1: [berta] -> [female]
# 2: [caesar] -> [male]
# 3: [adam] -> [male]



Example of a relation (index is a human, item a child of that human; 
a human may have more than one child):


r=.relation~of(("adam","henry"), ("adam","julia"), ("berta","julia"), ("caesar","denise"), 
("caesar","mark") )
say r~class":"
do with index i item o over r
 say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over r~allItems
 say "#" i":" pp(o)
end

Re: [Oorexx-devel] Segmentation fault in rexx executable

2019-02-20 Thread Moritz Hoffmann

It can help to enable core dumps, which can be used to debug after the
program faulted. On Linux, use the following command to enable them
for the current shell:

ulimit -c 100

Later use gdb to read them:

gdb rexx core

Moritz

On Wed, Feb 20, 2019 at 3:30 PM P.O. Jonsson  wrote:
>
> Thanks for the info, will build with debug and try to install the debugger 
> then. Hopefully next time I have more info.
>
> For what it is worth here the last lines in /var/log/kern.log (seems to point 
> to librexx.so):
>
> Feb 19 19:58:35 ubuntu18-04 kernel: [5.735603] audit: type=1400 
> audit(1550602715.004:11): apparmor="STATUS" operation="profile_load" 
> profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=587 
> comm="apparmor_parser"
> Feb 19 19:58:36 ubuntu18-04 kernel: [6.932503] IPv6: ADDRCONF(NETDEV_UP): 
> enp0s3: link is not ready
> Feb 19 19:58:36 ubuntu18-04 kernel: [6.936425] IPv6: ADDRCONF(NETDEV_UP): 
> enp0s3: link is not ready
> Feb 19 19:58:36 ubuntu18-04 kernel: [6.944100] e1000: enp0s3 NIC Link is 
> Up 1000 Mbps Full Duplex, Flow Control: RX
> Feb 19 19:58:36 ubuntu18-04 kernel: [6.944427] IPv6: 
> ADDRCONF(NETDEV_CHANGE): enp0s3: link becomes ready
> Feb 19 19:59:00 ubuntu18-04 kernel: [   31.532494] rfkill: input handler 
> disabled
> Feb 20 11:11:36 ubuntu18-04 kernel: [54782.226713] show_signal_msg: 28 
> callbacks suppressed
> Feb 20 11:11:36 ubuntu18-04 kernel: [54782.226717] rexx[10888]: segfault at 
> 18 ip 7ffa4466fff1 sp 7ffdf0fb72f0 error 4 in 
> librexx.so.5.0.0[7ffa44502000+219000]
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> Am 20.02.2019 um 15:08 schrieb Moritz Hoffmann :
>
> This is good to know but unfortunately not helpful. See
> https://sourceforge.net/p/oorexx/wiki/how-to-debug-oorexx/ on how to
> get more useful information.
>
> Cheers,
> Moritz
>
> On Wed, Feb 20, 2019 at 2:59 PM P.O. Jonsson  wrote:
>
>
> Dear developers,
>
> I am building & testing on a number of different platforms and sometimes on 
> macOS/Darwin I get this when I come to the test (it all runs from a shell 
> script):
>
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 13 Feb 2019 r11755
> Searching for test containers./Users/po/workspace/testooRexx.sh: line 37:  
> 4122 Segmentation fault: 11  rexx testOORexx.rex -s -X native_API
>
> Today I had the same on Ubuntu for the first time:
>
> Searching for test containers...
> /home/osboxes/workspace/testooRexx.sh: line 33: 10888 Segmentation fault  
> (core dumped) rexx testOORexx.rex -s -X native_API
> osboxes@ubuntu18-04:~/workspace$ ^C
> osboxes@ubuntu18-04:~/workspace$
>
> There was a crash report on the Ubuntu desktop indicating usr/bin/rexx to be 
> the culprit but apart from that I could get no further information out. 
> Trying again a 2nd time it always work.
>
> Is there a way (on macOS or Ubuntu or any other system) to find out more 
> about this? I build „release“ version on all systems. Is such information at 
> all useful for U?
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
>
> --
> Moritz Hoffmann;
> http://antiguru.de/
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



-- 
Moritz Hoffmann;
http://antiguru.de/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Segmentation fault in rexx executable

2019-02-20 Thread P.O. Jonsson

Duly noted. Tnx

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 20.02.2019 um 15:52 schrieb Moritz Hoffmann :
> 
> It can help to enable core dumps, which can be used to debug after the
> program faulted. On Linux, use the following command to enable them
> for the current shell:
> 
> ulimit -c 100
> 
> Later use gdb to read them:
> 
> gdb rexx core
> 
> Moritz
> 
> On Wed, Feb 20, 2019 at 3:30 PM P.O. Jonsson  wrote:
>> 
>> Thanks for the info, will build with debug and try to install the debugger 
>> then. Hopefully next time I have more info.
>> 
>> For what it is worth here the last lines in /var/log/kern.log (seems to 
>> point to librexx.so):
>> 
>> Feb 19 19:58:35 ubuntu18-04 kernel: [5.735603] audit: type=1400 
>> audit(1550602715.004:11): apparmor="STATUS" operation="profile_load" 
>> profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=587 
>> comm="apparmor_parser"
>> Feb 19 19:58:36 ubuntu18-04 kernel: [6.932503] IPv6: 
>> ADDRCONF(NETDEV_UP): enp0s3: link is not ready
>> Feb 19 19:58:36 ubuntu18-04 kernel: [6.936425] IPv6: 
>> ADDRCONF(NETDEV_UP): enp0s3: link is not ready
>> Feb 19 19:58:36 ubuntu18-04 kernel: [6.944100] e1000: enp0s3 NIC Link is 
>> Up 1000 Mbps Full Duplex, Flow Control: RX
>> Feb 19 19:58:36 ubuntu18-04 kernel: [6.944427] IPv6: 
>> ADDRCONF(NETDEV_CHANGE): enp0s3: link becomes ready
>> Feb 19 19:59:00 ubuntu18-04 kernel: [   31.532494] rfkill: input handler 
>> disabled
>> Feb 20 11:11:36 ubuntu18-04 kernel: [54782.226713] show_signal_msg: 28 
>> callbacks suppressed
>> Feb 20 11:11:36 ubuntu18-04 kernel: [54782.226717] rexx[10888]: segfault at 
>> 18 ip 7ffa4466fff1 sp 7ffdf0fb72f0 error 4 in 
>> librexx.so.5.0.0[7ffa44502000+219000]
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>> 
>> 
>> 
>> 
>> Am 20.02.2019 um 15:08 schrieb Moritz Hoffmann :
>> 
>> This is good to know but unfortunately not helpful. See
>> https://sourceforge.net/p/oorexx/wiki/how-to-debug-oorexx/ on how to
>> get more useful information.
>> 
>> Cheers,
>> Moritz
>> 
>> On Wed, Feb 20, 2019 at 2:59 PM P.O. Jonsson  wrote:
>> 
>> 
>> Dear developers,
>> 
>> I am building & testing on a number of different platforms and sometimes on 
>> macOS/Darwin I get this when I come to the test (it all runs from a shell 
>> script):
>> 
>> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 13 Feb 2019 r11755
>> Searching for test containers./Users/po/workspace/testooRexx.sh: line 37:  
>> 4122 Segmentation fault: 11  rexx testOORexx.rex -s -X native_API
>> 
>> Today I had the same on Ubuntu for the first time:
>> 
>> Searching for test containers...
>> /home/osboxes/workspace/testooRexx.sh: line 33: 10888 Segmentation fault 
>>  (core dumped) rexx testOORexx.rex -s -X native_API
>> osboxes@ubuntu18-04:~/workspace$ ^C
>> osboxes@ubuntu18-04:~/workspace$
>> 
>> There was a crash report on the Ubuntu desktop indicating usr/bin/rexx to be 
>> the culprit but apart from that I could get no further information out. 
>> Trying again a 2nd time it always work.
>> 
>> Is there a way (on macOS or Ubuntu or any other system) to find out more 
>> about this? I build „release“ version on all systems. Is such information at 
>> all useful for U?
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>> 
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> 
>> 
>> 
>> 
>> --
>> Moritz Hoffmann;
>> http://antiguru.de/
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 
> 
> 
> -- 
> Moritz Hoffmann;
> http://antiguru.de/
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Segmentation fault in rexx executable

2019-02-20 Thread P.O. Jonsson

Thanks for the info, will build with debug and try to install the debugger 
then. Hopefully next time I have more info.

For what it is worth here the last lines in /var/log/kern.log (seems to point 
to librexx.so):

Feb 19 19:58:35 ubuntu18-04 kernel: [5.735603] audit: type=1400 
audit(1550602715.004:11): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=587 
comm="apparmor_parser"
Feb 19 19:58:36 ubuntu18-04 kernel: [6.932503] IPv6: ADDRCONF(NETDEV_UP): 
enp0s3: link is not ready
Feb 19 19:58:36 ubuntu18-04 kernel: [6.936425] IPv6: ADDRCONF(NETDEV_UP): 
enp0s3: link is not ready
Feb 19 19:58:36 ubuntu18-04 kernel: [6.944100] e1000: enp0s3 NIC Link is Up 
1000 Mbps Full Duplex, Flow Control: RX
Feb 19 19:58:36 ubuntu18-04 kernel: [6.944427] IPv6: 
ADDRCONF(NETDEV_CHANGE): enp0s3: link becomes ready
Feb 19 19:59:00 ubuntu18-04 kernel: [   31.532494] rfkill: input handler 
disabled
Feb 20 11:11:36 ubuntu18-04 kernel: [54782.226713] show_signal_msg: 28 
callbacks suppressed
Feb 20 11:11:36 ubuntu18-04 kernel: [54782.226717] rexx[10888]: segfault at 18 
ip 7ffa4466fff1 sp 7ffdf0fb72f0 error 4 in 
librexx.so.5.0.0[7ffa44502000+219000]

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 20.02.2019 um 15:08 schrieb Moritz Hoffmann :
> 
> This is good to know but unfortunately not helpful. See
> https://sourceforge.net/p/oorexx/wiki/how-to-debug-oorexx/ on how to
> get more useful information.
> 
> Cheers,
> Moritz
> 
> On Wed, Feb 20, 2019 at 2:59 PM P.O. Jonsson  wrote:
>> 
>> Dear developers,
>> 
>> I am building & testing on a number of different platforms and sometimes on 
>> macOS/Darwin I get this when I come to the test (it all runs from a shell 
>> script):
>> 
>> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 13 Feb 2019 r11755
>> Searching for test containers./Users/po/workspace/testooRexx.sh: line 37:  
>> 4122 Segmentation fault: 11  rexx testOORexx.rex -s -X native_API
>> 
>> Today I had the same on Ubuntu for the first time:
>> 
>> Searching for test containers...
>> /home/osboxes/workspace/testooRexx.sh: line 33: 10888 Segmentation fault 
>>  (core dumped) rexx testOORexx.rex -s -X native_API
>> osboxes@ubuntu18-04:~/workspace$ ^C
>> osboxes@ubuntu18-04:~/workspace$
>> 
>> There was a crash report on the Ubuntu desktop indicating usr/bin/rexx to be 
>> the culprit but apart from that I could get no further information out. 
>> Trying again a 2nd time it always work.
>> 
>> Is there a way (on macOS or Ubuntu or any other system) to find out more 
>> about this? I build „release“ version on all systems. Is such information at 
>> all useful for U?
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>> 
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 
> 
> 
> -- 
> Moritz Hoffmann;
> http://antiguru.de/
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad loop counter on do...over ?

2019-02-20 Thread Gil Barmwater


I think we are on the right track but it needs a little tweaking:

t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
sayt~class":"

dowithindexiitemoovert
say"#"i":"pp(o)
end
say

say"--- the desired output:"
i=1
dowithindexidxitemoovert
say"#"i":"pp(idx) "->"pp(o)
i=i+1
end
say

say"--- how about this?"
dowithindexiitemidxovert~allindexes~supplier
say"#"i":"pp(idx) "->"pp(t[idx])
end
say

::routinepp
return"["arg(1)"]"

Gil B

---

On 2/20/2019 8:06 AM, Rony G. Flatscher wrote:

On 20.02.2019 07:06, Erich Steinböck wrote:


number a do with  over a table where the indices are not numbers,
or over a set or bag

Use
do with index i item j over c~allItems


This is *not* the same collection as "c", but an array of all of the 
items in the "c" MapCollection! The important information of which 
index is associated with which item gets lost.


The "do with...over" is meant to iterate over a supplier which is 
especially important for non-orderable collections.


In the case of Map/SetCollections the index object is as important as 
the item object, such that it cannot be forgone. (The supplier is the 
only means for Map/SetCollections to get all index-item-pairs, cf. 
e.g. for .Relation collections.)


---

One may be inclined to think that "do with...over" is fine for 
Orderable collections as array collections demonstrate:


a=("a","z","b")
say a~class":"
do with index i item o over a
 say "#" i":" pp(o)
end
say

l=.list~of("a","y","b")
say l~class":"
do with index i item o over l
 say "#" i":" pp(o)
end
say

::routine pp
   return "["arg(1)"]"
---

G:\test\oorexx\201902doover>test_do_over.rex
The Array class:
# 1: [a]
# 2: [z]
# 3: [b]

The List class:
# 0: [a]
# 1: [y]
# 2: [b]

However the index value starting out with 0 in the List collection 
case! The expected output in the case of the List class probably would 
have been:


The List class:
# 1: [a]
# 2: [y]
# 3: [b]

However, as one can see the List does not have a numeric index that 
start with 1, like it is the case with Array collections.


In the case of an Orderable collection only the "allitems" array will 
allow for using the index for numbering, starting with one (because an 
array always starts with 1):


l=.list~of("a","y","b")
say l~class":"
do with index i item o over l~allItems
 say "#" i":" pp(o)
end
say

::routine pp
   return "["arg(1)"]"
---

G:\test\oorexx\201902doover>test_do_over.rex
The List class:
# 1: [a]
# 2: [y]
# 3: [b]

=

Using allItems or allIndexes would not help in the case of 
Map/SetCollections, where the index object is as important as the item 
object.


Example with a Table collection:

t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
say t~class":"

do with index i item o over t
 say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over t~allItems
 say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over t~allIndexes
 say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over t
 say "#" i":" pp(idx) "->" pp(o)
 i=i+1
end
say

::routine pp
   return "["arg(1)"]"

Yielding:

The Table class:
# berta: [female]
# caesar: [male]
# adam: [male]

--- now with t~allItems:
# 1: [female]
# 2: [male]
# 3: [male]

--- now with t~allIndexes:
# 1: [berta]
# 2: [caesar]
# 3: [adam]

--- the desired output:
# 1: [berta] -> [female]
# 2: [caesar] -> [male]
# 3: [adam] -> [male]



Example of a relation (index is a human, item a child of that human; a 
human may have more than one child):


r=.relation~of(("adam","henry"), ("adam","julia"), ("berta","julia"), ("caesar","denise"), 
("caesar","mark") )
say r~class":"
do with index i item o over r
 say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over r~allItems
 say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over r~allIndexes
 say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over r
 say "#" i":" pp(idx) "->" pp(o)
 i=i+1
end
say

::routine pp
   return "["arg(1)"]"

Yielding:

The Relation class:
# caesar: [mark]

[Oorexx-devel] Haiku now at full speed.

2019-02-20 Thread Jason Martin

Still do not have enviroment but this patch speeds things 6 fold.

--- oorexx-haiku-5.0.0/common/platform/unix/SysSemaphore.cpp 2019-02-20
07:09:11.132382720 +
+++ oorexx-haiku-5.0.0/common/platform/unix/SysSemaphore.cpp 2019-02-20
07:57:36.212074496 +
@@ -56,7 +56,7 @@
 #include 
 #endif

-#if defined(OPSYS_SUN)
+#if defined(OPSYS_SUN) || defined(__HAIKU__)
 #include 
 #endif


~> rexx -v
Open Object Rexx Version 5.0.0 r11789
Build date: Feb 20 2019
Addressing mode: 64
Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
Copyright (c) 2005-2019 Rexx Language Association. All rights reserved.
This program and the accompanying materials are made available under the
terms
of the Common Public License v1.0 which accompanies this distribution or at
http://www.oorexx.org/license.html
~> rexx rexxcps.rex
- REXXCPS 2.1 -- Measuring REXX clauses/second -
 REXX version is: REXX-ooRexx_5.0.0(MT)_64-bit 6.05 20 Feb 2019
   System is: HAIKU
   Averaging: 100 measures of 100 iterations

Total (full DO): 0.02474159 secs (average of 100 measures of 100 iterations)
Time for one iteration (1000 clauses) was: 0.0002474159 seconds

 Performance: 4041777 REXX clauses per second

~> cat cmd.rex
'ls'~>
~> rexx cmd.rex
 1 *-* 'ls'
   >>>   "ls"
   +++   "RC(127)"
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Segmentation fault in rexx executable

2019-02-20 Thread Moritz Hoffmann

This is good to know but unfortunately not helpful. See
https://sourceforge.net/p/oorexx/wiki/how-to-debug-oorexx/ on how to
get more useful information.

Cheers,
Moritz

On Wed, Feb 20, 2019 at 2:59 PM P.O. Jonsson  wrote:
>
> Dear developers,
>
> I am building & testing on a number of different platforms and sometimes on 
> macOS/Darwin I get this when I come to the test (it all runs from a shell 
> script):
>
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 13 Feb 2019 r11755
> Searching for test containers./Users/po/workspace/testooRexx.sh: line 37:  
> 4122 Segmentation fault: 11  rexx testOORexx.rex -s -X native_API
>
> Today I had the same on Ubuntu for the first time:
>
> Searching for test containers...
> /home/osboxes/workspace/testooRexx.sh: line 33: 10888 Segmentation fault  
> (core dumped) rexx testOORexx.rex -s -X native_API
> osboxes@ubuntu18-04:~/workspace$ ^C
> osboxes@ubuntu18-04:~/workspace$
>
> There was a crash report on the Ubuntu desktop indicating usr/bin/rexx to be 
> the culprit but apart from that I could get no further information out. 
> Trying again a 2nd time it always work.
>
> Is there a way (on macOS or Ubuntu or any other system) to find out more 
> about this? I build „release“ version on all systems. Is such information at 
> all useful for U?
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



-- 
Moritz Hoffmann;
http://antiguru.de/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Segmentation fault in rexx executable

2019-02-20 Thread Enrico Sorichetti via Oorexx-devel

I got the same a few times …
unfortunately thats a bug almost impossible to fix
Being in the right place at the right time 

I did build a debug version, run rexx under the lldb covers 
But I never got anything out of it ( NEVER CRASHED )

E


On 20 Feb 2019, at 14:59, P.O. Jonsson  wrote:
> 
> Dear developers,
> 
> I am building & testing on a number of different platforms and sometimes on 
> macOS/Darwin I get this when I come to the test (it all runs from a shell 
> script):
> 
> REXX-ooRexx_5.0.0(MT)_64-bit 6.05 13 Feb 2019 r11755
> Searching for test containers./Users/po/workspace/testooRexx.sh: line 37:  
> 4122 Segmentation fault: 11  rexx testOORexx.rex -s -X native_API
> 
> Today I had the same on Ubuntu for the first time:
> 
> Searching for test containers...
> /home/osboxes/workspace/testooRexx.sh: line 33: 10888 Segmentation fault  
> (core dumped) rexx testOORexx.rex -s -X native_API
> osboxes@ubuntu18-04:~/workspace$ ^C
> osboxes@ubuntu18-04:~/workspace$
> 
> There was a crash report on the Ubuntu desktop indicating usr/bin/rexx to be 
> the culprit but apart from that I could get no further information out. 
> Trying again a 2nd time it always work.
> 
> Is there a way (on macOS or Ubuntu or any other system) to find out more 
> about this? I build „release“ version on all systems. Is such information at 
> all useful for U?
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Segmentation fault in rexx executable

2019-02-20 Thread P.O. Jonsson

Dear developers,

I am building & testing on a number of different platforms and sometimes on 
macOS/Darwin I get this when I come to the test (it all runs from a shell 
script):

REXX-ooRexx_5.0.0(MT)_64-bit 6.05 13 Feb 2019 r11755
Searching for test containers./Users/po/workspace/testooRexx.sh: line 37:  4122 
Segmentation fault: 11  rexx testOORexx.rex -s -X native_API

Today I had the same on Ubuntu for the first time:

Searching for test containers...
/home/osboxes/workspace/testooRexx.sh: line 33: 10888 Segmentation fault  
(core dumped) rexx testOORexx.rex -s -X native_API
osboxes@ubuntu18-04:~/workspace$ ^C
osboxes@ubuntu18-04:~/workspace$

There was a crash report on the Ubuntu desktop indicating usr/bin/rexx to be 
the culprit but apart from that I could get no further information out. Trying 
again a 2nd time it always work.

Is there a way (on macOS or Ubuntu or any other system) to find out more about 
this? I build „release“ version on all systems. Is such information at all 
useful for U?

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad loop counter on do...over ?

2019-02-20 Thread Rony G. Flatscher

On 20.02.2019 07:06, Erich Steinböck wrote:
>
> number a do with  over a table where the indices are not numbers, or over 
> a set or bag
>
>  
> Use
> do with index i item j over c~allItems

This is *not* the same collection as "c", but an array of all of the items in 
the "c" MapCollection!
The important information of which index is associated with which item gets 
lost.

The "do with...over" is meant to iterate over a supplier which is especially 
important for
non-orderable collections. 

In the case of Map/SetCollections the index object is as important as the item 
object, such that it
cannot be forgone. (The supplier is the only means for Map/SetCollections to 
get all
index-item-pairs, cf. e.g. for .Relation collections.)

---

One may be inclined to think that "do with...over" is fine for Orderable 
collections as array
collections demonstrate:

a=("a","z","b")
say a~class":"
do with index i item o over a
say "#" i":" pp(o)
end
say

l=.list~of("a","y","b")
say l~class":"
do with index i item o over l
say "#" i":" pp(o)
end
say

::routine pp
  return "["arg(1)"]"
---

G:\test\oorexx\201902doover>test_do_over.rex
The Array class:
# 1: [a]
# 2: [z]
# 3: [b]

The List class:
# 0: [a]
# 1: [y]
# 2: [b]

However the index value starting out with 0 in the List collection case! The 
expected output in the
case of the List class probably would have been:

The List class:
# 1: [a]
# 2: [y]
# 3: [b]

However, as one can see the List does not have a numeric index that start with 
1, like it is the
case with Array collections.

In the case of an Orderable collection only the "allitems" array will allow for 
using the index for
numbering, starting with one (because an array always starts with 1):

l=.list~of("a","y","b")
say l~class":"
do with index i item o over l~allItems
say "#" i":" pp(o)
end
say

::routine pp
  return "["arg(1)"]"
---

G:\test\oorexx\201902doover>test_do_over.rex
The List class:
# 1: [a]
# 2: [y]
# 3: [b]

=

Using allItems or allIndexes would not help in the case of Map/SetCollections, 
where the index
object is as important as the item object.

Example with a Table collection:

t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
say t~class":"

do with index i item o over t
say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over t~allItems
say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over t~allIndexes
say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over t
say "#" i":" pp(idx) "->" pp(o)
i=i+1
end
say

::routine pp
  return "["arg(1)"]"

Yielding:

The Table class:
# berta: [female]
# caesar: [male]
# adam: [male]

--- now with t~allItems:
# 1: [female]
# 2: [male]
# 3: [male]

--- now with t~allIndexes:
# 1: [berta]
# 2: [caesar]
# 3: [adam]

--- the desired output:
# 1: [berta] -> [female]
# 2: [caesar] -> [male]
# 3: [adam] -> [male]



Example of a relation (index is a human, item a child of that human; a human 
may have more than one
child):

r=.relation~of(("adam","henry"), ("adam","julia"), ("berta","julia"), 
("caesar","denise"), ("caesar","mark") )
say r~class":"
do with index i item o over r
say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over r~allItems
say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over r~allIndexes
say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over r
say "#" i":" pp(idx) "->" pp(o)
i=i+1
end
say

::routine pp
  return "["arg(1)"]"

Yielding:

The Relation class:
# caesar: [mark]
# caesar: [denise]
# berta: [julia]
# adam: [julia]
# adam: [henry]

--- now with t~allItems:
# 1: [mark]
# 2: [denise]
# 3: [julia]
# 4: [julia]
# 5: [henry]

--- now with t~allIndexes:
# 1: [caesar]
# 2: [caesar]
# 3: [berta]
# 4: [adam]
# 5: [adam]

--- the desired output:
# 1: [caesar] -> [mark]
# 2: [caesar] -> [denise]
# 3: [berta] -> [julia]
# 4: [adam] -> [julia]
# 5: [adam] -> [henry]

Having a "counter" subkeyword would allow numbering without the need to know 
the kind of collection
that is being iterated. E.g.

List exampl

Re: [Oorexx-devel] Also, CMakeList.txt same thing or me, tried to override?

[Oorexx-devel] Fwd: [Oorexx-svn] SF.net SVN: oorexx-code-0:[11792] main/trunk/common/platform/unix/ SysSemaphore.cpp

Re: [Oorexx-devel] Haiku now at full speed.

Re: [Oorexx-devel] Also, CMakeList.txt same thing or me, tried to override?

Re: [Oorexx-devel] Haiku now at full speed.

Re: [Oorexx-devel] Haiku now at full speed.

Re: [Oorexx-devel] Haiku now at full speed.

Re: [Oorexx-devel] Ad loop counter on do...over ?

Re: [Oorexx-devel] Segmentation fault in rexx executable

Re: [Oorexx-devel] Segmentation fault in rexx executable

Re: [Oorexx-devel] Segmentation fault in rexx executable

Re: [Oorexx-devel] Ad loop counter on do...over ?

[Oorexx-devel] Haiku now at full speed.

Re: [Oorexx-devel] Segmentation fault in rexx executable

Re: [Oorexx-devel] Segmentation fault in rexx executable

[Oorexx-devel] Segmentation fault in rexx executable

Re: [Oorexx-devel] Ad loop counter on do...over ?

17 matches

Site Navigation

Mail list logo

Footer information