search

trealla-prolog / trealla

A compact, efficient Prolog interpreter written in plain-old C.
MIT License
274 stars 13 forks source link

bigint arithmetic gets killed #76

Closed Jean-Luc-Picard-2021 closed 1 year ago

Jean-Luc-Picard-2021 commented 2 years ago

Why and by whom does it get killed, on WSL2:

$ ./tpl -v
Trealla Prolog (c) Infradig 2020-2022, v2.5.18
$ ./tpl
?- ['mpatan.p', 'libbf.p', 'treallastub.p'].
   true.
?- time((between(1,1000,_), mp_pi(8192, _), fail; true)).
Killed

The test case works in SWI-Prolog with default memory settings.

See attachments for test case: libbf.p.log mpatan.p.log treallastub.p.log

Jean-Luc-Picard-2021 commented 2 years ago

Also a nice example how getbit/2 and divmod/4 could speed-up. What I could test so far was:

?- time((between(1,1000,_), mp_pi(53, _), fail; true)).
   % Time elapsed 0.576s
   true.

?- time((between(1,1000,_), mp_pi(1024, _), fail; true)).
   % Time elapsed 11.7s
   true.

SWI-Prolog does the same, also in WSL2 and with GMP, twice as fast. Maybe these missing built-ins are to blame:

/* File treallastub.p */
testbit(M, I) :- M /\ (1<<I) =\= 0.

divmod(A, B, X, Y) :- X is A div B, Y is A mod B.
infradig commented 2 years ago

On Wed, Nov 9, 2022 at 4:00 AM Jean-Luc-Picard-2021 < @.***> wrote:

Why does it get killed, on WSL2:

$ ./tpl -v Trealla Prolog (c) Infradig 2020-2022, v2.5.18 $ ./tpl ?- ['mpatan.p', 'libbf.p', 'treallastub.p']. true. ?- time((between(1,1000,_), mppi(8192, ), fail; true)). Killed

The test case works in SWI-Prolog with default memory settings.

See attachments for test case: libbf.p.log https://github.com/trealla-prolog/trealla/files/9963917/libbf.p.log mpatan.p.log https://github.com/trealla-prolog/trealla/files/9963918/mpatan.p.log treallastub.p.log https://github.com/trealla-prolog/trealla/files/9963919/treallastub.p.log

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSESMWCGQYB3TXE3QBIDWHKIK5ANCNFSM6AAAAAAR2TAHEE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Jean-Luc-Picard-2021 commented 2 years ago

Does the Trealla Prolog consult bail out on the first error. If not the consult should show a second error. This is what I get when I consult it with SWI-Prolog, also the use_module/1 should show

image

some error? Doesn't it? I had some problems diagnosing my first attempt in running it, because it ignores the ['libbf.p'] in ['mpatan.p']. Here is a different version, with the two syntax errors removed:

libbf.p.log

infradig commented 2 years ago

Added divmod/4 but the other requires bit-twiddling in imath.c (which I don't understand all that well) so I will do when time permits.

On Wed, Nov 9, 2022 at 7:02 AM Jean-Luc-Picard-2021 < @.***> wrote:

Oops, sorry, wrong version, try this:

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76#issuecomment-1307820934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEVCU3JCTVJHT6PVKWTWHK5W7ANCNFSM6AAAAAAR2TAHEE . You are receiving this because you commented.Message ID: @.***>

Jean-Luc-Picard-2021 commented 2 years ago

If I am not totally mistaken, I only call getbit/2 for positive bigints. It seems getbit/2 for negative numbers is a little bit more difficult. But since SWI-Prolog throws anyway an exception when I call msb/1 for a negative number, my code never gets to the point

of getbit/1 with a negative number. If I am not totally mistaken, the ISO core standard leaves open what the bitwise operations do for negative numbers? Anyway negative numbers and bitwise operations seem not so important for the use case of arbitrary floats.

So it wouldn't do much harm if the negative case is slower than the positive case. The problem of the ISO core standard implementation specific behaviour of bitwise operations, is that with bigints the idea anyway breaks down somehow. At least I got this impression

and first adopted the Java BigInteger bit operations, and now with Dogelog Player, the good news is that the bitwise operations are also there in JavaScript and Python. The bad news is, I have not yet resolved the issue of msb/1, lsb/1 and getbit/1 for these

platforms, nevertheless I am posting tickets to other Prolog systems. Well if the other Prolog system is C based, its more open than JavaScript or Python, possibly easier to add a missing built-in. So forgive me for asking all this stuff, and even putting reminders.

Jean-Luc-Picard-2021 commented 2 years ago

Ok, its divmod/4 is there:

$ ./tpl -v
Trealla Prolog (c) Infradig 2020-2022, v2.5.25
$ ./tpl
?- divmod(1000,26,X,Y).
   X = 38, Y = 12.
?- X is 26*38+12.
   X = 1000.

Will do some regression testing, hopefully the abort goes away?

Jean-Luc-Picard-2021 commented 2 years ago

Regression testing gives me, not much faster, and still killed. How can I avoid the "killed"? Give it more memory somehow? I am runnng from WSL2 without some special configuration:

$ ./tpl
?- ['mpatan.p', 'libbf.p', 'treallastub.p'].
   true.
?- member(N, [53, 1024, 8192]), time((between(1,1000,_),
mp_pi(N, _), fail; true)), fail; true.
   % Time elapsed 0.567s
   % Time elapsed 11.3s
Killed

Maybe there is no garbage collection aka environment trimming in this tail recursive loop, which is the working horse of the atan implementation:

% mp_atan_horner(+Part, +Pair, +Integer, -Pair)
mp_atan_horner((0,S), _, _, S) :- !.
mp_atan_horner(U, H, K, Y) :-
   mp_atan_next(U, H, K, V),
   mp_atan_horner(V, H, K, Y).
infradig commented 2 years ago

Don't know since I can't test it.

On Wed, Nov 9, 2022 at 10:41 PM Jean-Luc-Picard-2021 < @.***> wrote:

Ok, its divmod/4 is there:

$ ./tpl -v Trealla Prolog (c) Infradig 2020-2022, v2.5.25 $ ./tpl ?- divmod(1000,26,X,Y). X = 38, Y = 12. ?- X is 26*38+12. X = 1000.

Will do some regression testing, hopefully the abort goes away?

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76#issuecomment-1308693694, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEVGTJ4WGKTN3AMV2NDWHOLZJANCNFSM6AAAAAAR2TAHEE . You are receiving this because you commented.Message ID: @.***>

Jean-Luc-Picard-2021 commented 2 years ago

Do you mean you cannot reproduce the Killed? You need to edit treallastub.p and remove the divmod/4 stub. I get it in WSL2, I don't know other platforms.

I do not press Ctrl-C or something, it kills itself:

image

infradig commented 2 years ago

Whom?

The OOM-killer.

Jean-Luc-Picard-2021 commented 2 years ago

Ok, out-of-memory. Strange I can run the example with a 512 MB memory limit, in Java based Prolog. Isn't that a gap in the garbage collection of Trealla Prolog?

SWI-Prolog stays in a 1 GB memory limit:

image

Jean-Luc-Picard-2021 commented 2 years ago

Maybe a problem of the between/3 failure loop. If I use smaller iterations I can run the test case:

$ ./tpl
?- ['treallastub.p', 'crarith.p', 'mpatan.p'].
   true.
?- mp_pi(53, X), cr_decode(X, R).
   X = (884279719003555, -48), R = 3.141592653589793.
?- member((N,K),[(53,2600),(1024,150),(8192,9)]), time((between(1,K,_)
mp_pi(N, _), fail; true)), fail; true.
   % Time elapsed 1.63s
   % Time elapsed 1.88s
   % Time elapsed 1.66s
   true.
infradig commented 2 years ago

There's a leak in bigint - bigint division.

On Thu, Nov 10, 2022 at 7:04 AM Jean-Luc-Picard-2021 < @.***> wrote:

Ok, out-of-memory. Strange I can run the example with a 512 MB memory limit, in Java based Prolog. Isn't that a gap in the garbage collection of Trealla Prolog?

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76#issuecomment-1309372016, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEU4QZDF6Z5H4AKR2JTWHQGUDANCNFSM6AAAAAAR2TAHEE . You are receiving this because you commented.Message ID: @.***>

Jean-Luc-Picard-2021 commented 2 years ago

But there is nothing new to test yet, right? I get:

$ git pull
Already up to date.

So today is my holiday, my free day, free of testing?

infradig commented 2 years ago

The fix posted doesn't fix the issue, just one memory issue.

infradig commented 2 years ago

Hmm, no leaks when it's run with no top-level choice-point...

$ valgrind tpl ==188356== Memcheck, a memory error detector ?- ['../tpl-stuff/mpatan.p', '../tpl-stuff/libbf.p', '../tpl-stuff/treallastub.p']. true. ?- mppi(8192, ),fail. false. ?- halt. ==188356== LEAK SUMMARY: ==188356== definitely lost: 0 bytes in 0 blocks ==188356== indirectly lost: 0 bytes in 0 blocks ==188356== possibly lost: 0 bytes in 0 blocks ==188356== still reachable: 320,159 bytes in 222 blocks ==188356== suppressed: 0 bytes in 0 blocks $

But...

$ valgrind tpl ==188366== Memcheck, a memory error detector ==188366== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ?- ['../tpl-stuff/mpatan.p', '../tpl-stuff/libbf.p', '../tpl-stuff/treallastub.p']. true. ?- mppi(8192, ),fail;true. true. ?- ==188366== LEAK SUMMARY: ==188366== definitely lost: 1,164,600 bytes in 29,115 blocks ==188366== indirectly lost: 31,040,712 bytes in 26,774 blocks ==188366== possibly lost: 10,248 bytes in 8 blocks ==188366== still reachable: 320,159 bytes in 222 blocks ==188366== suppressed: 0 bytes in 0 blocks $

It should be easy to find out why memory is not being recovered in this case... but it's got me stumped for now.

Jean-Luc-Picard-2021 commented 2 years ago

Does this also have a memory leak?

?- mp_pi(53, _),fail;true.
true.

Do you have smallints and bigints in your Prolog system?

P.S.: The problem of garbage collection for (is)/2 is extremly hairy, there are so much issues that blend into each other. Also in my two Prolog systems I have different solutions.

Jean-Luc-Picard-2021 commented 2 years ago

It seems not to be a problem of failversus fail; true. I guess the smallints are promoted to bigint, at least their result. And already there something gets lost.

I get these results for fail with the option --leak-check=full:

$ valgrind --leak-check=full ./tpl
==170== Memcheck, a memory error detector
==170== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==170== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==170== Command: ./tpl
==170==
?- ['treallastub.p', 'crarith.p', 'mpatan.p'].
   true.
?- mp_pi(53, _),fail.
   false.
?-
==170==
==170== HEAP SUMMARY:
==170==     in use at exit: 213,597 bytes in 369 blocks
==170==   total heap usage: 19,200 allocs, 18,831 frees, 76,912,368 bytes allocated
==170==
==170== 144 (80 direct, 64 indirect) bytes in 2 blocks are definitely lost in loss record 25 of 80
==170==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==170==    by 0x12C37C: fn_iso_powi_2 (in /home/rburs/trealla/tpl)
==170==    by 0x122147: call_builtin (in /home/rburs/trealla/tpl)
==170==    by 0x13677A: fn_iso_is_2 (in /home/rburs/trealla/tpl)
==170==    by 0x191336: start (in /home/rburs/trealla/tpl)
==170==    by 0x14C8C4: run (in /home/rburs/trealla/tpl)
==170==    by 0x18B214: pl_eval (in /home/rburs/trealla/tpl)
==170==    by 0x115EAB: main (in /home/rburs/trealla/tpl)
==170==
==170== 144 (80 direct, 64 indirect) bytes in 2 blocks are definitely lost in loss record 26 of 80
==170==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==170==    by 0x12342B: fn_iso_add_2 (in /home/rburs/trealla/tpl)
==170==    by 0x122147: call_builtin (in /home/rburs/trealla/tpl)
==170==    by 0x13677A: fn_iso_is_2 (in /home/rburs/trealla/tpl)
==170==    by 0x191336: start (in /home/rburs/trealla/tpl)
==170==    by 0x14C8C4: run (in /home/rburs/trealla/tpl)
==170==    by 0x18B214: pl_eval (in /home/rburs/trealla/tpl)
==170==    by 0x115EAB: main (in /home/rburs/trealla/tpl)
==170==
==170== 288 (160 direct, 128 indirect) bytes in 4 blocks are definitely lost in loss record 32 of 80
==170==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==170==    by 0x13447C: fn_iso_mul_2 (in /home/rburs/trealla/tpl)
==170==    by 0x122147: call_builtin (in /home/rburs/trealla/tpl)
==170==    by 0x13677A: fn_iso_is_2 (in /home/rburs/trealla/tpl)
==170==    by 0x191336: start (in /home/rburs/trealla/tpl)
==170==    by 0x14C8C4: run (in /home/rburs/trealla/tpl)
==170==    by 0x18B214: pl_eval (in /home/rburs/trealla/tpl)
==170==    by 0x115EAB: main (in /home/rburs/trealla/tpl)
==170==
==170== 432 (240 direct, 192 indirect) bytes in 6 blocks are definitely lost in loss record 33 of 80
==170==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==170==    by 0x134787: fn_iso_mul_2 (in /home/rburs/trealla/tpl)
==170==    by 0x122147: call_builtin (in /home/rburs/trealla/tpl)
==170==    by 0x13677A: fn_iso_is_2 (in /home/rburs/trealla/tpl)
==170==    by 0x191336: start (in /home/rburs/trealla/tpl)
==170==    by 0x14C8C4: run (in /home/rburs/trealla/tpl)
==170==    by 0x18B214: pl_eval (in /home/rburs/trealla/tpl)
==170==    by 0x115EAB: main (in /home/rburs/trealla/tpl)
==170==
==170== 1,152 (640 direct, 512 indirect) bytes in 16 blocks are definitely lost in loss record 49 of 80
==170==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==170==    by 0x135F28: fn_iso_negative_1 (in /home/rburs/trealla/tpl)
==170==    by 0x122147: call_builtin (in /home/rburs/trealla/tpl)
==170==    by 0x13677A: fn_iso_is_2 (in /home/rburs/trealla/tpl)
==170==    by 0x191336: start (in /home/rburs/trealla/tpl)
==170==    by 0x14C8C4: run (in /home/rburs/trealla/tpl)
==170==    by 0x18B214: pl_eval (in /home/rburs/trealla/tpl)
==170==    by 0x115EAB: main (in /home/rburs/trealla/tpl)
==170==
==170== 1,368 (760 direct, 608 indirect) bytes in 19 blocks are definitely lost in loss record 50 of 80
==170==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==170==    by 0x1232B1: fn_iso_add_2 (in /home/rburs/trealla/tpl)
==170==    by 0x122147: call_builtin (in /home/rburs/trealla/tpl)
==170==    by 0x13677A: fn_iso_is_2 (in /home/rburs/trealla/tpl)
==170==    by 0x191336: start (in /home/rburs/trealla/tpl)
==170==    by 0x14C8C4: run (in /home/rburs/trealla/tpl)
==170==    by 0x18B214: pl_eval (in /home/rburs/trealla/tpl)
==170==    by 0x115EAB: main (in /home/rburs/trealla/tpl)
==170==
==170== 1,656 (920 direct, 736 indirect) bytes in 23 blocks are definitely lost in loss record 52 of 80
==170==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==170==    by 0x12D7E4: fn_iso_shr_2 (in /home/rburs/trealla/tpl)
==170==    by 0x122147: call_builtin (in /home/rburs/trealla/tpl)
==170==    by 0x13677A: fn_iso_is_2 (in /home/rburs/trealla/tpl)
==170==    by 0x191336: start (in /home/rburs/trealla/tpl)
==170==    by 0x14C8C4: run (in /home/rburs/trealla/tpl)
==170==    by 0x18B214: pl_eval (in /home/rburs/trealla/tpl)
==170==    by 0x115EAB: main (in /home/rburs/trealla/tpl)
==170==
==170== LEAK SUMMARY:
==170==    definitely lost: 2,880 bytes in 72 blocks
==170==    indirectly lost: 2,304 bytes in 72 blocks
==170==      possibly lost: 0 bytes in 0 blocks
==170==    still reachable: 208,413 bytes in 225 blocks
==170==         suppressed: 0 bytes in 0 blocks
==170== Reachable blocks (those to which a pointer was found) are not shown.
==170== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==170==
==170== For lists of detected and suppressed errors, rerun with: -s
==170== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
Jean-Luc-Picard-2021 commented 2 years ago

Is Trealla supposed to dispose everything upon exit? Does it dispose the consulted Prolog texts before exiting? I am using Ctrl-D. I have such a clean-up in one of my

Prolog systems, in the other one not yet. Was updating to release 2.6.2 trealla, now valgrind shows me, readline also leaks?

==594== 200 (32 direct, 168 indirect) bytes in 1 blocks are definitely lost in loss record 34 of 84
==594==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==594==    by 0x4983BAC: xmalloc (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1)
==594==    by 0x497A7C2: rl_add_undo (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1)
==594==    by 0x497B7D6: rl_delete_text (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1)
==594==    by 0x4980DA0: _rl_rubout_char (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1)
==594==    by 0x4961E97: _rl_dispatch_subseq (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1)
==594==    by 0x4962CC9: readline_internal_char (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1)
==594==    by 0x496BD14: readline (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1)
==594==    by 0x13B906: history_readline_eol (in /home/rburs/trealla/tpl)
==594==    by 0x115E48: main (in /home/rburs/trealla/tpl)
infradig commented 2 years ago

Not seeing it on Ubuntu. What are you doing?

On Tue, 15 Nov 2022, 07:42 Jean-Luc-Picard-2021, @.***> wrote:

Was updating to release 2.6.2, readline also leaks?

==594== 200 (32 direct, 168 indirect) bytes in 1 blocks are definitely lost in loss record 34 of 84 ==594== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==594== by 0x4983BAC: xmalloc (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1) ==594== by 0x497A7C2: rl_add_undo (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1) ==594== by 0x497B7D6: rl_delete_text (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1) ==594== by 0x4980DA0: _rl_rubout_char (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1) ==594== by 0x4961E97: _rl_dispatch_subseq (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1) ==594== by 0x4962CC9: readline_internal_char (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1) ==594== by 0x496BD14: readline (in /usr/lib/x86_64-linux-gnu/libreadline.so.8.1) ==594== by 0x13B906: history_readline_eol (in /home/rburs/trealla/tpl) ==594== by 0x115E48: main (in /home/rburs/trealla/tpl)

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76#issuecomment-1314446737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEWXOPVKYHPC6NU6VPLWIKW4JANCNFSM6AAAAAAR2TAHEE . You are receiving this because you commented.Message ID: @.***>

Jean-Luc-Picard-2021 commented 2 years ago

I could reproduce it already once or twice. You need to edit the input text after the prompt "?- ", and recall the history via up and down arrow.

But I am too clumsy to remember the exact steps, but I could just reproduce it again. I guess I have to pay more attention, will then be able to

write down the exact steps. Ok here is a method, the input was:

image

But I did edit the line ['trealla.p', 'crarith.p', 'mpatan.p'] to ['trealla.p', 'mpatan.p'], and then did an overwrite of the line to ['trealla.p', 'crarith.p', 'mpatan.p'] by using the

arrow keys. Because of these input manipulations:

image

Probably a bug in readline. It doesn't clear some undo buffer, when recalling the history. Not sure whether you can influence the bug by some key binding hooks, implementing them differently?

Jean-Luc-Picard-2021 commented 2 years ago

Was redoing testing after the recent divmod/4 fixes. Still a little problem somewhere:

$ ./tpl -v
Trealla Prolog (c) Infradig 2020-2022, v2.6.38
$ ./tpl
?- ['crarith.p', 'mpatan.p', 'dcutil.p', 'trealla.p'].
   true.
?- time((between(1,1000,_), mp_pi(8192, _), fail; true)).
Killed
infradig commented 2 years ago

Yes, a problem with heap / GC.

On Tue, Nov 29, 2022 at 9:41 AM Jean-Luc-Picard-2021 < @.***> wrote:

Was redoing testing after the recent divmod/4 fixes. Still a little problem somewhere:

$ ./tpl -v Trealla Prolog (c) Infradig 2020-2022, v2.6.38 $ ./tpl ?- ['crarith.p', 'mpatan.p', 'dcutil.p', 'trealla.p']. true. ?- time((between(1,1000,_), mppi(8192, ), fail; true)). Killed

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76#issuecomment-1329890037, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEW53PEX4F2BK2AJINTWKU7KZANCNFSM6AAAAAAR2TAHEE . You are receiving this because you commented.Message ID: @.***>

Jean-Luc-Picard-2021 commented 2 years ago

Are there kangaroos at trealla beach?

infradig commented 2 years ago

Probably, but kangaroos don't usually surf.

On Tue, 29 Nov 2022, 10:01 Jean-Luc-Picard-2021, @.***> wrote:

Are there kangaroos at trealla beach?

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76#issuecomment-1329901169, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEWBWTKX6CZUGXATUWTWKVBW3ANCNFSM6AAAAAAR2TAHEE . You are receiving this because you commented.Message ID: @.***>

Jean-Luc-Picard-2021 commented 2 years ago

How much would be a domestic flight from sydney?

infradig commented 2 years ago

No idea. You'd probably fly to Perth and then up. I'm an East Coast person.

On Tue, 29 Nov 2022, 10:07 Jean-Luc-Picard-2021, @.***> wrote:

How much would be a domestic flight from sydney?

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76#issuecomment-1329904749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEUYAIFJWQFBPKO4DGLWKVCKNANCNFSM6AAAAAAR2TAHEE . You are receiving this because you commented.Message ID: @.***>

infradig commented 1 year ago

Nice beach in Gerringong from what I remember of my childhood.

On Mon, Feb 6, 2023 at 9:57 AM Jean-Luc-Picard-2021 < @.***> wrote:

I was in Sydney and Gerringong during last december. Was my first time in Australia.

— Reply to this email directly, view it on GitHub https://github.com/trealla-prolog/trealla/issues/76#issuecomment-1418302330, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFNKSEX7NL2C5MRXUQPKAWLWWA465ANCNFSM6AAAAAAR2TAHEE . You are receiving this because you commented.Message ID: @.***>