Hi Andras,
> Perfect, it works as expected on macOS.
Great! :)
> Finally I’ve got demoApp working: the culprit was the Safari browser.
> With Firefox it works!
I see. But then the Pil GUI must somehow be faulty too.
☺/ A!ex
--
UNSUBSCRIBE:
Hi Alex,
Perfect, it works as expected on macOS.
Finally I’ve got demoApp working: the culprit was the Safari browser.
With Firefox it works!
Regards,
Andras Pahi
> On 2021. Apr 17., at 16:54, Alexander Burger wrote:
>
> On Sat, Apr 17, 2021 at 04:35:09PM +0200, Alexander Burger wrote:
>>
On Sat, Apr 17, 2021 at 04:35:09PM +0200, Alexander Burger wrote:
> OK, as ppoll() works fine on Linux (tests passed), I will keep it. This covers
> most use cases, including Servers (Debian), PilBox (Android) and smaller stuff
> (Raspi).
>
> I put an #ifdef for other systems, using poll() and
On Sat, Apr 17, 2021 at 04:21:53PM +0200, Alexander Burger wrote:
> Hmm, I'm just testing the ppoll() version ... What to do?
OK, as ppoll() works fine on Linux (tests passed), I will keep it. This covers
most use cases, including Servers (Debian), PilBox (Android) and smaller stuff
(Raspi).
I
Hi Andras,
> Just one remark, ppoll(2) is Linux-specific.
Oh, you are right! Too bad, it would have been a perfect replacement!
Good that you mention this, I did not pay attention.
> I know there is a perfectly portable API - Linux.
Yes :)
Hmm, I'm just testing the ppoll() version ... What
Hi Alex,
Just one remark, ppoll(2) is Linux-specific.
I know there is a perfectly portable API - Linux.
Regards,
Andras Pahi
> On 2021. Apr 17., at 15:53, Alexander Burger wrote:
>
> On Sat, Apr 17, 2021 at 02:15:42PM +0200, Alexander Burger wrote:
>> But as you saw in my last mail, the whole
On Sat, Apr 17, 2021 at 02:15:42PM +0200, Alexander Burger wrote:
> But as you saw in my last mail, the whole question is obsolete. I have to
> adjust
> pil21 anyway.
I will use ppoll(2).
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Hi Andras,
> Maybe the definition of
>
> #define __INT_MAX__ 2147483647
>
> could be used ? It is predefined by the clang/gcc preprocessor.
Yeah, should be portable enough.
But as you saw in my last mail, the whole question is obsolete. I have to adjust
pil21 anyway.
☺/ A!ex
--
Hi all,
On Sat, Apr 17, 2021 at 01:02:20PM +0200, Alexander Burger wrote:
> Hmm, too bad! I tested here with 64-bit integers with
>
>#if (int)-1 == 0x
>
> and it worked.
Uuhh! Sorry! I was completely off the track!
'int' is *always* 32 bit in size, on every system I've
Hi Alex,
Maybe the definition of
#define __INT_MAX__ 2147483647
could be used ? It is predefined by the clang/gcc preprocessor.
Regards,
Andras Pahi
> On 2021. Apr 17., at 13:02, Alexander Burger wrote:
> Unfortunately, "#if sizeof(int) == 4" is not allowed in C, that's why I used
> the
>
Hi Andras,
> According to the man page on macOS, poll returns:
>
> [EINVAL] The nfds argument is greater than OPEN_MAX or the
> timeout argument is less than -1.
That explains it! So the specification of poll() is indeed different from the
Linux one.
>
Hi Alex,
Thank you for looking after this.
According to the man page on macOS, poll returns:
[EINVAL] The nfds argument is greater than OPEN_MAX or the
timeout argument is less than -1.
The check at compile time is not triggered on macOS, the following
Hi Andras,
> It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
> values which when casted to (int) results in values less than -1 (eg. -3).
> This results in EINVAL errors in poll().
The EINVAL is indeed strange. According to the man page any negative timout
should
Hi,
It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
values which when casted to (int) results in values less than -1 (eg. -3).
This results in EINVAL errors in poll().
I have inserted a code snippet which truncates the timeout to -1 then I can get
to the login page
$ picolisp -wait
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
[fds=0x0][nfds=0][timeout=9223372036854775807]
Hi Alex,
Thank you for your suggestions, I have traced listen and wait and both have
The parameters are as expected (Ms is NIL, Sd is 17).
As Mike tested on macOS Big Sur and it worked, the problem is in my setup.
Regards,
Andras
> On 2021. Apr 15., at 19:11, Alexander Burger wrote:
>
> Hi
Hi Mike,
Thank you for the test, I am still on Mojave.
I will check my setup where it went wrong.
Regards,
Andras
> On 2021. Apr 15., at 21:13, Mike wrote:
>
> Andras,
>
> https://webirc.envs.net/uploads/5d228d2686705b27/8AB6ED6B-5EAC-4CBC-BCF8-84BB26447763.jpeg
> this is my try on latest
Andras,
https://webirc.envs.net/uploads/5d228d2686705b27/8AB6ED6B-5EAC-4CBC-BCF8-84BB26447763.jpeg
this is my try on latest big sur
April 15, 2021 7:53 PM, "Andras Pahi" wrote:
> Hi,
>
> I grabbed the latest pil21.tgz and demoApp.tgz.
>
> "pil @lib/test.l +" runs without errors.
>
> On
Hi Andras,
>
> /pil app/main.l -ap~main -'go 4040' +
> 6538 = 58885 48782252818959702~
> ap: !? (wait Ms T "Sd")
> Select error: Invalid argument
> ...
> It has the same behavior as the previous version of pil21.
Yeah, I thought about it, and came to the conclusion that today's change in
Hi,
I grabbed the latest pil21.tgz and demoApp.tgz.
"pil @lib/test.l +" runs without errors.
On macOS I've got
/pil app/main.l -ap~main -'go 4040' +
6538 = 58885 48782252818959702~
ap: !? (wait Ms T "Sd")
Select error: Invalid argument
ap? Select error: Invalid argument
ap? Select error:
> On Thu, Apr 15, 2021 at 08:32:32AM +0200, Alexander Burger wrote:
>> That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is
>> 49
>> days (as opposed to the 292 million years (292MY) in 64 bits).
>
> Not even that! For signed 32 bits it is only 24 days :(
>
> Should I
On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote:
> Looks like I should do that.
Done!
Can somebody test on a Macintosh or other BSDs?
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
On Thu, Apr 15, 2021 at 08:42:04AM +0200, Alexander Burger wrote:
> Should I change the design of waitFd() to use only 32 bits?
Looks like I should do that.
poll(2) is badly specified, using only int for the timeout. But we have to live
with that, there may be other ABIs (other BSDs?) which
On Thu, Apr 15, 2021 at 08:32:32AM +0200, Alexander Burger wrote:
> That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is
> 49
> days (as opposed to the 292 million years (292MY) in 64 bits).
Not even that! For signed 32 bits it is only 24 days :(
Should I change the
On Thu, Apr 15, 2021 at 08:07:21AM +0200, Andras Pahi wrote:
> Hi,
>
> Yes, ‘int’ is 32bit on macOS, even when compiling to 64bit.
> The pil21 demoApp does not work on macOS.
Thanks Andras!
That's too bad! If poll(2) uses only 32 bits for the timeout, the maximum is 49
days (as opposed to the
Hi,
Yes, ‘int’ is 32bit on macOS, even when compiling to 64bit.
The pil21 demoApp does not work on macOS.
pahihu
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 16
sizeof(void*) = 8
> On 2021.
On Thu, Apr 15, 2021 at 07:46:35AM +0200, Alexander Burger wrote:
> Hi all,
>
> I just stumbled across this mail in the archive. I have not received it, and
> the
> sending e-mail address seems just "picolisp".
>
> > picolisp Sun, 11 Apr 2021 15:05:25 -0700
Ah, that's all right! There is
Hi all,
I just stumbled across this mail in the archive. I have not received it, and the
sending e-mail address seems just "picolisp".
> picolisp Sun, 11 Apr 2021 15:05:25 -0700
>
> I am trying to fix infinite select errors about 292MY.
>
> On my mac (int)9223372036854775807 == -1 which means no
I am trying to fix infinite select errors about 292MY.
src/lib.c:
int32_t gPoll(struct pollfd *fds, int32_t nfds, int64_t timeout) {
if (timeout == 9223372036854775807) { // 292MY
int i = nfds;
do
if (--i < 0)
return 0;
while
29 matches
Mail list logo
