ease post an example snippet of this new syntax?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
last param) will break code that
> otherwise would be fine.
How do C codebases deal with this regarding varargs? I've never done anything
large scale or long term in C so I'm not sure what those programmers think of
varargs. Maybe they know something I don't
. ;) I guess others don't see it this way however.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ing is
basically what we know as "varargs", i.e. an unspecified amount of extra
parameters. This common pattern in Format() is a good example of a last
parameter array of const which doesn't really gain anything by adding the extra
[] every time. I smell another mode switch. :)
Format('%
array of const is the last (or only) parameter the compiler could infer it
right? i.e.
DoThis(firstParam, [1,2,3]);
doesn't really need the [] in this case since the last parameters would have to
be an array of const.
Regards,
Ryan Joseph
___
fpc-
and_cdecl_routines
> ) and we DO NOT WANT to support this.
Sorry to interject but I'm just curious why this hardline stance was taken.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi
really anxious to
get this integrated already. :)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
the system unit using
search_system_type? There must be some utility function but I don’t know where
to look.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo
> On Oct 7, 2019, at 11:10 AM, Ben Grasset wrote:
>
> As far as "approval", if I recall correctly Sven said he intended to review
> it eventually.
>
Excellent. I’ve already had multiple times I could have used this. Who can we
bribe? ;)
Reg
ion as its
> currently in proposed patch.
> Maybe it worth of consideration. If not, it's ok.
>
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/lis
Very eager for closures. Btw, what’s the status Blaise? I didn’t hear back
since last month or so.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ooding
back into the project and so they need to be deleted. My git client handles it
well enough but the 20k+ files stall out the UI a little. ;)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal
log --graph
* commit c5a6c2c0822d6c869a788a98a144e739a97d517a (HEAD -> generic_constants,
origin/generic_constants)
| Author: Ryan Joseph
| Date: Sat Jul 20 09:40:58 2019 -0400
|
| fixed bugs with range checking and constants + added 2 tests
|
* commit 49de8113a1eb29b368d89d9e2fb7fa7c9
it history or my patches will get rejected. If that weren’t the case I
would just do a merge and release the patch with full commit history.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepa
t I’m
not sure what.
Ryans-MacBook-Pro-2:fpc-git ryanjoseph$ git log --graph
* commit c5a6c2c0822d6c869a788a98a144e739a97d517a (HEAD -> generic_constants,
origin/generic_constants)
| Author: Ryan Joseph
| Date: Sat Jul 20 09:40:58 2019 -0400
|
| fixed bugs with range check
rebase origin/master” on the feature branch BEFORE I merged
the master but it says "Current branch gen-const-new is up to date.”. What is
rebase doing that it thinks the feature branch is up to date?
Regards,
Ryan Joseph
___
fpc-dev
git complains "only commits reachable from HEAD can be
modified”. Is this not how I’m supposed to keep my local feature branch
up-to-date with the server? Any advice would be great.
Regards,
Ryan Joseph
___
fpc-devel maillist - f
cy thing and it should be improved.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt
> wrote:
>
> You are assuming here that there is a problem. Has it occurred to you that
> maybe there is no problem and that a solution is simply not needed?
How is this not a problem? Sorry I don’t follow you.
Regards,
ide the usual copy operator call
which happens every time. I guess the only other viable option would be a
modeswitch or some other compiler directive to toggle on/off.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.fr
nericptr/freepascal/tree/moveop
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
this but I wanted to post the patch so you
could see how it worked and if it’s worth it in terms of added complexity.
https://bugs.freepascal.org/view.php?id=35825
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
this just today. Hopefully it’s small
enough it can get merged without waiting for months. ;)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
:
>
I guess I could see people using var/out for this:
if b[v] then
v.doSomething;
I’m not sure if it’s a bug or not so I’ll wait for the compiler teams response
and I don’t care either way, I just want constref to work. :)
Regards,
Ryan Joseph
__
ter testing it myself that is not the case.
>
Yeah that doesn’t make any sense to me and it goes against the idea of
properties anyways. To the compiler team, is this a bug? If it is I will make a
report along with setters not allowing constref.
Rega
var/out bug if you don’t mind. Just to be sure.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
rstand that’s
just a calling convention change for compatibility with other systems.
That means the only bug I’m interested in is allowing array property setters to
use constref.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.free
confirm if that’s correct and I’ll make another bug report.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
f" does.
>
Why does that require a special switch? Also, I thought it was determined that
allowed “out” in array properties was a bug?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
write SetValue;
default; // ERROR: Illegal symbol for property access
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
fairly
> well:
>
Excellent, now everyone is happy.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
t supported.
>
I was thinking more along the lines of making read/write access part of the
overloading but that’s kind of pushing it in terms of what overloading means.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists
> On Jul 8, 2019, at 6:11 PM, Ben Grasset wrote:
>
> Also, here's a longer (but much better because it doesn't require the data
> type provided by the user to itself be directly assignable to a pointer)
> version of that:
>
That’s getting creative, I like it, thanks.
Reg
to how the properties are currently structured this means we
can’t use the setter without passing pointers:
list[0] := @vec;
That’s why I think it’s worthing considering the overloading properties to
solve this.
Regards,
Ryan Joseph
___
fpc-d
: T write SetValue; default;
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
the file directly rather
> than copying and pasting its contents would be much safer if changes need to
> be made.
Yeah I wonder if {$INCLUDESTRINGFILE} could leverage the changes with multiline
strings so it gets included also. The original patch has been sitting there
dead since 2014
hem.”
I indeed didn’t notice the bug report and just thought this was accepted
behavior.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Jul 6, 2019, at 4:09 PM, Ondrej Pokorny wrote:
>
> On 06.07.2019 20:03, Ryan Joseph wrote:
>> Yeah that’s correct.
>>
>> Here’s my bug report:
>>
>> https://bugs.freepascal.org/view.php?id=35809
>
> Did you just create a duplicate bug report
ted.
Yeah that’s correct.
Here’s my bug report:
https://bugs.freepascal.org/view.php?id=35809
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
can do a post processing if the user wants to indent but remove the white space
later. Just make a RemoveLeadingWhiteSpace function or something and add it to
the RTL.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freep
; overload;
function GetValue(k0,k1: variant): TJSON; overload;
function GetValue(k0,k1,k2: variant): TJSON; overload;
function GetValue(k0,k1,k2,k3: variant): TJSON; overload;
property Values[key: variant]: TJSON read GetValue; default;
Regards,
Ryan Joseph
m at all and go back to what ever you were doing
before. Either way we get more options available to us so this feature is a big
win imo.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepas
else {
fragColor = texture(textures[int(vertexUVMap)], vertexTexCoord.st);
if (vertexColor.a < fragColor.a) {
fragColor.a = vertexColor.a;
}
}
// TODO: testing
fragColor = vec4(1,0,0,1);
}
`;
var
s: ansistring;
begin
writeln(b);
end.
Reg
you’ll see the error gets
moved to the right location.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
error also
doesn’t make any sense. To the compiler team, could we make that error actually
tell us what’s wrong?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
rd.st);
if (vertexColor.a < fragColor.a) {
fragColor.a = vertexColor.a;
}
}
// TODO: testing
fragColor = vec4(1,0,0,1);
}
`;
var
s: ansistring = lines;
begin
writeln(lines);
end.
Regards,
Ryan Joseph
> On Jul 5, 2019, at 10:36 PM, Ben Grasset wrote:
>
> What error, though?
String constant too long while ansistrings are disabled
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freep
ething to do with that.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
are messing it up?
I get "String constant too long while ansistrings are disabled”.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
existing code because H+ is global for the unit it appears.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
r the entire unit. It’s
probably not related to your code I agree. If anyone know if this is a bug/can
be fixed please let me know.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
;
} else {
fragColor = texture(textures[int(vertexUVMap)], vertexTexCoord.st);
if (vertexColor.a < fragColor.a) {
fragColor.a = vertexColor.a;
}
}
}`;
{$pop}
begin
writeln(lines);
end.
Regards,
Ryan Joseph
___
fpc
anks. I don’t even need H+ in delphi mode so maybe it’s enabled by default.
In ObjFPC mode H+ doesn’t seem to be working unless it’s before the program
section.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.fr
r = vertexColor;
} else {
fragColor = texture(textures[int(vertexUVMap)], vertexTexCoord.st);
if (vertexColor.a < fragColor.a) {
fragColor.a = vertexColor.a;
}
}
}`;
{$pop}
begin
writeln(lines);
end.
Regards,
Ryan Joseph
_
}`;
{$pop}
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
olor = vertexColor;
} else {
fragColor = texture(textures[int(vertexUVMap)], vertexTexCoord.st);
if (vertexColor.a < fragColor.a) {
fragColor.a = vertexColor.a;
}
}
}`;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc
rtexColor.a < fragColor.a) {
fragColor.a = vertexColor.a;
}
}
}`;
{$h-}
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
tring being too long.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
rd.st);
if (vertexColor.a < fragColor.a) {
fragColor.a = vertexColor.a;
}
}
}`;
var
l: string = lines;
begin
writeln(l);
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.o
> On Jul 5, 2019, at 10:40 AM, Ben Grasset wrote:
>
> Not quite sure exactly what you mean.
>
If use {$multilinestringlineending cr} then the string only prints “ ddd”. If
I use {$multilinestringlineending crlf} then all the text prints.
Regards,
talk.
It still feels intuitively like we should be using double-quotes instead of
back ticks but it’s still very nice.
program test;
{$modeswitch multilinestrings}
{$multilinestringlineending cr}
const lines = `
aaa
bbb
ccc
ddd
`;
begin
writeln(lines);
end.
Regards,
haracter? I thought another use of `` strings would be that you
don’t need to escape apostrophes using ‘'.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
n GitHub so we can test it. We’re not getting anywhere going
back and forth over email.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
join distribution_line_items on
distribution_line_items.unique_id_no =
distribution_stop_information.unique_id_no
where
distribution_line_items.datetime_created > '2/22/2017' and
customer_no = '91000'';
begin
end.
Regards
ho says to themselves that they
explicitly want a language that doesn’t support multi-line comments or strings?
I use both of these all the time in PHP so it’s really hard to understand why
this would be opposed.
Regards,
Ryan Joseph
___
fpc-devel m
e but it’s nice to
just toss things into source files sometimes for quick and dirty stuff.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Jul 3, 2019, at 2:43 PM, Michael Van Canneyt
> wrote:
>
> There is also still:
> https://bugs.freepascal.org/view.php?id=25536
What does this do and why has it been sitting there since 2014 if it’s useful?
Regards,
"no".
I would use it for GLSL shaders embedded in code or maybe other scripts like
Lua. Why is it a bad thing? Seems like an obvious win to have long strings in
Pascal.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-deve
could
> safely directly and immediately assume that any use of them was specifically
> either the opening or closing of a multiline string.
What about double quotes? I think those are available and it makes sense.
Regards,
Ryan Joseph
_
o fix some of these weird bugs that we found with
properties (did anyone file a bug report yet?).
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> property StringArray[Index: Integer]: string read GetString;
> property StringArray: TTestObjectEnumerator read GetString;
> end;
No, it’s just for [] properties. Is that allowed in Delphi?
Regards,
Ryan Joseph
tValue; default;
> end;
And btw what was decided about the syntax? I think it was determined it was
valid in Delphi but is it going to be allowed in ObjFPC mode? If that’s how
Delphi does it I don’t see why they allow the [] to contain any parameters at
all since they don’t map to anyth
eepascal.org/view.php?id=28949
Yes, I’ve made a patch to allow overriding the actual property
(https://bugs.freepascal.org/view.php?id=35772).
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepa
default;
end;
function tINIFile.GetAsText( akey:integer):PAnsiChar;
begin
end;
function tINIFile.GetAsText(ans,asection,akey:PAnsiChar):PAnsiChar;
begin
end;
var
o: tINIFile;
s: PAnsiChar;
begin
s := o[1];
s := o['a','b','c'];
end.
Regards,
en? allowing var and out in properties
seems wrong also.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
d be prevented. I just found out
default properties allowed overloading by accidental means so this may be
another similar matter. Those should maybe be prevented also but that could
break existing code.
Regards,
Ryan Joseph
___
fpc-devel ma
As an side since you’re talking about optimizations what would it take to make
the copy/addref record operators be inline? Unless I’m mistaken that’s one of
the bigger issues that makes custom ref counted objects slower than built in
compiler types. Just curious...
Regards,
Ryan Joseph
compatibility?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
I’m putting this into the pipeline and I’ll make a better patch after it’s
reviewed since I’m not sure I got everything right.
https://bugs.freepascal.org/view.php?id=35772
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel
use git locally, bit given how big this task will be and
> also how iterative it will be, I will likely use GitHub in this case.
Great, put up what you have if you some time. I’d be curious to see how this
works.
Regards,
Ryan Joseph
o just press a button and push changes to the
server.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
GitHub you publish to? Just curious to see your work on
this...
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_XML" in the compiler's
> source code, all units will have a "NAME-node-dump.xml" file generated
> alongside the compiled source.
Great, now you can finish pure functions. ;)
Regards,
Ryan Joseph
___
fpc-devel maill
> On Jun 21, 2019, at 1:59 PM, Ryan Joseph wrote:
>
> Even though overloads are allowed the actual name isn’t overloaded so you
> MUST access without the name to get overloading affects. I didn’t overload
> the actual name because properties aren’t really functions and as su
;
begin
v := c[1,'f'];
end.
Regards,
Ryan Joseph
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Jun 20, 2019, at 4:59 PM, Sven Barth via fpc-devel
> wrote:
>
> It will need to be be allowed for Delphi compatibility anyway:
> https://bugs.freepascal.org/view.php?id=29056
>
Well that settles it. ;)
Regards,
Ryan Joseph
_
tension
> MyStrings[0] MyStrings['Name']
>
> Still you must be careful, because what is meant by
> MyStrings['0'] ... is it a type error or is actually the name meant ?
It’s basically the same as any other overloaded method so I don’t see where the
problem could be.
Regards,
R
o
c[0] or c[‘key’] without the property name. It feels to me like we’re being
held back by the choice of the word default. How can we get around that? Seems
like a silly thing to be getting in our way.
Regards,
Ryan Joseph
___
fpc-devel mail
;
property IndexS[index: string]: TValue read GetValueWithString; default;
end;
o := c[index]; // IndexI wins
o := c[‘key’]; // IndexS wins
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https
t. See the dynamic array example
again. The only way the record knows it was copied into the array is via the
copy operator.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/ma
> On Jun 19, 2019, at 4:48 PM, Ben Grasset wrote:
>
> What I meant was, does `Copy` actually serve any particular purpose at all
> versus just overloading the assignment operator normally?
>
It’s used for making reference counted types at the user level.
Regards,
.Create(1),TMyRec.Create(1),TMyRec.Create(1)];
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
hese
operators at all. FPC seems to have lots of non-inlinable code these days which
is too bad. Maybe the LLVM backend will fix that someday?
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepas
hich (for now at least)
would only affect records which had a move operator. In theory the concept
could be extended to dynamic arrays and other reference counted types but
that’s another story.
Regards,
Ryan Joseph
___
fpc-devel maillis
ways called on all assignments. Try actually running
that and you’ll see. :)
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
ptimizations here anywhere.
Seems like an obvious win to me to gain some performance and avoid unnecessary
copies.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> On Jun 16, 2019, at 6:00 PM, Benito van der Zander wrote:
>
> Objects are much more useful than classes or records
Now that’s an inflammatory statement! :) But seriously, I do miss record
inheritance from C++, C#, Swift when I’m in Pascal.
Regards,
Ry
> On Jun 15, 2019, at 11:40 AM, Karoly Balogh (Charlie/SGR)
> wrote:
>
> Hi,
>
> On Sat, 15 Jun 2019, J. Gareth Moreton wrote:
>
>> Ryan Joseph requested that I reply to this to show that it's in the
>> mailing list. Hopefully the technical problems can be
101 - 200 of 328 matches
Mail list logo
