Op 2010-10-19 07:19, Hans-Peter Diettrich het geskryf:
So there's left nothing what I could do for FPC.
Welcome to the club of uphill battles. :)
PS:
[this comment applies in general, not necessarily to this specific thread's
feature]
I agree that code clean-up, code restructuring and
2010/10/19 Alexander Klenin kle...@gmail.com:
On Tue, Oct 19, 2010 at 16:19, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
So there's left nothing what I could do for FPC.
I suggest you start a git-maintained fork.
This way, developers can transition to your version gradaully,
avoiding
19.10.2010 14:49, Vincent Snijders wrote:
So maybe you cannot do anything for FPC, except creating an Enhanced FPC.
About a year ago I created a document which describes what features FPC
requires to compile recent Delphi code. If someone does not know what to
do for FPC then he is welcome
2010/10/19 Graeme Geldenhuys graemeg.li...@gmail.com:
I guess that doesn't mean Florian or some other core developer must accept
your patch or new features, but that's the beauty of open source software.
Simply fork the project and continue with your own Object Pascal compiler.
Many projects
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is Unicode string support.
What Hans-Peter meant is that even if he does implement Unicode String
support, that would require changes in the compiler. Florian apparently
doesn't like any changes to the compiler, plus he
Op 2010-10-19 09:07, Vincent Snijders het geskryf:
Yes, but I doubt this possible fork will be, but feel free to prove me wrong.
Nobody will know, until a fork has been made. As for your opinion that it
will simply fail is a bit of thumb sucking. Some commercial entity could
easily fork FPC,
Sent from my iPhone
On 19 Oct 2010, at 06:50, Alexander Klenin kle...@gmail.com wrote:
On Tue, Oct 19, 2010 at 16:19, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
So there's left nothing what I could do for FPC.
I suggest you start a git-maintained fork.
I have been biting my
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is Unicode string support.
What Hans-Peter meant is that even if he does implement Unicode String
support, that would require changes in the compiler. Florian apparently
On 10/19/2010 08:59 AM, Paul Ishenin wrote:
The most wanted feature is Unicode string support.
Which means new Delphi Strings with dynamic code support ?
There is a branch in the svn. How is the state and the pan ?
Other stuff recently discussed is thread support (not or not perfectly
Am 19.10.2010 10:12, schrieb Florian Klaempfl:
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is Unicode string support.
What Hans-Peter meant is that even if he does implement Unicode String
support, that would require
On 10/19/2010 09:32 AM, Graeme Geldenhuys wrote:
'plus he sees no need for Unicode
String support, so why would others. ;-)
Some colleagues of mine need to port their projects from non-Delphi to
the new Unicode enabled version.
They are not amused.
I did try to work with the
I meant to write:
-- Some colleagues of mine need to port their projects from
non-Unicode Delphi to the new Unicode enabled Delphi version.
Sorry
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 19.10.2010 10:20, schrieb Sven Barth:
Am 19.10.2010 10:12, schrieb Florian Klaempfl:
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is Unicode string support.
What Hans-Peter meant is that even if he does implement
Op 2010-10-19 10:18, Michael Schnell het geskryf:
The most wanted feature is Unicode string support.
Which means new Delphi Strings with dynamic code support ?
There is a branch in the svn. How is the state and the pan ?
I still have local changes that add more unicode support and improved
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is Unicode string support.
What Hans-Peter meant is that even if he does implement Unicode String
support, that would require changes in the compiler. Florian apparently
Am 19.10.2010 10:31, schrieb Florian Klaempfl:
Am 19.10.2010 10:20, schrieb Sven Barth:
Am 19.10.2010 10:12, schrieb Florian Klaempfl:
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is Unicode string support.
What
On 19 Oct 2010, at 10:40, Graeme Geldenhuys wrote:
I still have local changes that add more unicode support and improved
unicode support under Linux, but the unicode branch is currently not
compilable on my system - due to the latest merge done in that branch. So
my work regarding that
Op 2010-10-19 10:37, Michael Van Canneyt het geskryf:
Changes to the compiler are allowed and have been implemented at various
times with very good results. Paul is living proof of this.
...and you totally missed my sarcastic intent with that message.
DoDi's path forward seems clear... Fork
On 10/19/2010 07:50 AM, Alexander Klenin wrote:
I suggest you start a git-maintained fork.
Of course git is superior to svn for this purpose.
Is the base repository hosted on a git server ?
-Michael
___
fpc-devel maillist -
On Tuesday 19 October 2010 11:10:29 Matt Emson wrote:
On 19 Oct 2010, at 06:50, Alexander Klenin kle...@gmail.com wrote:
On Tue, Oct 19, 2010 at 16:19, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
So there's left nothing what I could do for FPC.
I suggest you start a
Op 2010-10-19 10:51, Jonas Maebe het geskryf:
You still have not said a single time what the actual problem is that you are
having.
I believe I have, but I can't remember all the errors, and I have no time
to search the mail archive Just tried to compile that branch again
under 64-bit
Op 2010-10-19 10:06, Michael Schnell het geskryf:
On 10/19/2010 07:50 AM, Alexander Klenin wrote:
I suggest you start a git-maintained fork.
Of course git is superior to svn for this purpose.
Is the base repository hosted on a git server ?
Yes, I maintain the mirror on GitHub.
On Tue, Oct 19, 2010 at 10:23 AM, Michael Schnell mschn...@lumino.de wrote:
And I in the German Lazarus Forum watched several beginners trying to use
this Lazarus version for doing programs dealing with German text.
They were a lot more than not amused but rather deeply frustrated.
?
On 19 Oct 2010, at 11:24, Felipe Monteiro de Carvalho wrote:
On Tue, Oct 19, 2010 at 10:23 AM, Michael Schnell mschn...@lumino.de wrote:
And I in the German Lazarus Forum watched several beginners trying to use
this Lazarus version for doing programs dealing with German text.
They were a
Graeme Geldenhuys wrote:
Op 2010-10-19 10:51, Jonas Maebe het geskryf:
You still have not said a single time what the actual problem is that you are
having.
I believe I have, but I can't remember all the errors, and I have no time
to search the mail archive Just tried to compile that
Op 2010-10-19 11:31, Marc Weustink het geskryf:
What if you use a released compiler as starting compiler ?
(other versions are not supported)
Like I said, this was just a quick test so I could post some output.
Originally I did use the latest released compiler - 2.4.0 I believe.
I'll try
Am 19.10.2010 11:43, schrieb Jonas Maebe:
On 19 Oct 2010, at 11:18, Graeme Geldenhuys wrote:
cresstr.pas(149,178) Error: Identifier not found DefaultSystemCodePage
cresstr.pas(165,117) Error: Identifier not found DefaultSystemCodePage
cresstr.pas(170,126) Error: Identifier not found
Am 19.10.2010 09:37, schrieb Michael Van Canneyt:
[...]
Currently all we got from Hans Peter were unmanageable patches
supposedly fixing things that were not broken or in need of fixing.
If he had first done some smaller things - take your pick in the bugtracker
- and we had seen that this
On 19 Oct 2010, at 11:18, Graeme Geldenhuys wrote:
cresstr.pas(149,178) Error: Identifier not found DefaultSystemCodePage
cresstr.pas(165,117) Error: Identifier not found DefaultSystemCodePage
cresstr.pas(170,126) Error: Identifier not found DefaultSystemCodePage
cresstr.pas(320) Fatal:
On 19 Oct 2010, at 11:45, Sven Barth wrote:
Am 19.10.2010 11:43, schrieb Jonas Maebe:
I'm not sure how that's related to the merge I did. DefaultSystemCodePage is
a system unit variable that was introduced in the cpstrnew branch. The error
message suggests that you are trying to compile
Am 19.10.2010 11:52, schrieb Jonas Maebe:
On 19 Oct 2010, at 11:45, Sven Barth wrote:
Am 19.10.2010 11:43, schrieb Jonas Maebe:
I'm not sure how that's related to the merge I did. DefaultSystemCodePage is a
system unit variable that was introduced in the cpstrnew branch. The error
message
Op 2010-10-19 10:49, Martin Schreiber het geskryf:
FPC is used in *production*!
I agree, but this shouldn't prevent enhancements, forward thinking and
innovation.
We can't accept experimental changes of the compiler architecture in
trunk.
For production use, and for stability, that is
Op 2010-10-19 11:43, Jonas Maebe het geskryf:
I'm not sure how that's related to the merge I did.
DefaultSystemCodePage is a system unit variable that was introduced in
the cpstrnew branch.
What good is a merge that breaks the compiling of the compiler?
The error message suggests that you
On 19 Oct 2010, at 12:23, Graeme Geldenhuys wrote:
Op 2010-10-19 11:43, Jonas Maebe het geskryf:
I'm not sure how that's related to the merge I did.
DefaultSystemCodePage is a system unit variable that was introduced in
the cpstrnew branch.
What good is a merge that breaks the compiling
2010/10/19 Graeme Geldenhuys graemeg.li...@gmail.com:
Op 2010-10-19 09:07, Vincent Snijders het geskryf:
Yes, but I doubt this possible fork will be, but feel free to prove me wrong.
Nobody will know, until a fork has been made. As for your opinion that it
will simply fail is a bit of thumb
Op 2010-10-19 12:33, Jonas Maebe het geskryf:
As mentioned in other mails, the compilation order is first the new RTL,
then the new compiler
I saw your reply to Sven. I didn't know that, and never used it like that
before. I guess I was lucky.
Anyway, just downloaded and installed a fresh
On 19 Oct 2010, at 12:47, Graeme Geldenhuys wrote:
Op 2010-10-19 12:33, Jonas Maebe het geskryf:
As mentioned in other mails, the compilation order is first the new RTL,
then the new compiler
I saw your reply to Sven. I didn't know that, and never used it like that
before. I guess I
Ah, just to close the issue. The original text from Michael Schnell
was ambiguous and I understood he was talking about the Lazarus
unicode support, but now I see that he could be talking about the Free
Pascal unicode support ... which are 2 different things.
Indeed, if he was about Lazarus
In our previous episode, Graeme Geldenhuys said:
As mentioned in other mails, the compilation order is first the new RTL,
then the new compiler
I saw your reply to Sven. I didn't know that, and never used it like that
before. I guess I was lucky.
Am 19.10.2010 12:18, schrieb Graeme Geldenhuys:
Like I've said a million times before, the management of the FPC project
seems a bit off (sorry if this offends some of you, don't take it
personally). Hardly anybody looks at the various branches, so to truly test
something new
Indeed, it's
Am 19.10.2010 12:47, schrieb Graeme Geldenhuys:
/opt/fpc-2.4.0/bin/fpc -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU../../rtl/units/x86_64-linux -Cg -dx86_64 -Us -Sg system.pp
Free Pascal Compiler version 2.4.0 [2009/12/18] for x86_64
Copyright (c) 1993-2009 by Florian Klaempfl
Am 19.10.2010 14:02, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 22:44, Florian Klaempfl flor...@freepascal.org
wrote:
Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
First Pascal-like languages and later C.
FPC's main developer doesn't see a need for it.
Indeed. Please tell what
On Wed, Oct 20, 2010 at 00:11, Florian Klaempfl flor...@freepascal.org wrote:
Am 19.10.2010 14:48, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl flor...@freepascal.org
wrote:
I actually teach compiler construction at the university,
and he correctly noted that
On 10/19/2010 11:24 AM, Felipe Monteiro de Carvalho wrote:
?
They were deeply frustrated that we have a simple and reliable Unicode
support which supports any language in the world?
I'm not going to discuss (again) what a beginner will do and what he
will see when stepping character by
Hi,
Florian mentioned that the compiler is well tested, and I can see there are
many .pp files in the src/tests/ hierarchy.
Where would I look for the RTL and FCL unit tests? Is it the code in
src/tests/test/units/fpcunit/? If so, is that all of them, or is there
another directory (eg: maybe
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 00:11, Florian Klaempfl flor...@freepascal.org wrote:
Am 19.10.2010 14:48, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl flor...@freepascal.org wrote:
I actually teach compiler construction at
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote:
Hi,
Florian mentioned that the compiler is well tested, and I can see there are
many .pp files in the src/tests/ hierarchy.
Where would I look for the RTL and FCL unit tests? Is it the code in
src/tests/test/units/fpcunit/? If so, is that all
On Tue, Oct 19, 2010 at 23:02, Florian Klaempfl flor...@freepascal.org wrote:
Am 19.10.2010 13:54, schrieb Alexander Klenin:
from fixing case and reformatting of Math unit
This does not help anybody ;)
See, you have already rejected it ;-)
The initial motivation was that current unit have
Am 19.10.2010 12:07, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 17:59, Paul Ishenin i...@kmiac.ru wrote:
19.10.2010 14:49, Vincent Snijders wrote:
So maybe you cannot do anything for FPC, except creating an Enhanced FPC.
About a year ago I created a document which describes what
On Tue, Oct 19, 2010 at 22:44, Florian Klaempfl flor...@freepascal.org wrote:
Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
First Pascal-like languages and later C.
FPC's main developer doesn't see a need for it.
Indeed. Please tell what a C front end to FPC helps? FPC has no
advantage
Am 19.10.2010 14:48, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl flor...@freepascal.org
wrote:
Am 19.10.2010 14:02, schrieb Alexander Klenin:
The topic of this thread and the patch was/is alternative parsers. As
you worked on the case of string stuff (or your
On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl flor...@freepascal.org wrote:
Am 19.10.2010 14:02, schrieb Alexander Klenin:
The topic of this thread and the patch was/is alternative parsers. As
you worked on the case of string stuff (or your student) you might also
know that the fpc parser is
On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt
mich...@freepascal.org wrote:
2) I'd say that at least half of his mistakes could be avoided
by better code structure of FPC -- he was really uncomfortable
using strange records and pchars instead of normal objects and strings.
That has
On Tuesday, 19. October 2010 15.42:30 Alexander Klenin wrote:
2) I'd say that at least half of his mistakes could be avoided
by better code structure of FPC -- he was really uncomfortable
using strange records and pchars instead of normal objects and strings.
Hmm, strange records and pchars
Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt
mich...@freepascal.org wrote:
2) I'd say that at least half of his mistakes could be avoided
by better code structure of FPC -- he was really uncomfortable
using strange records and pchars instead of normal objects and
Am 19.10.2010 13:54, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 22:41, Florian Klaempfl flor...@freepascal.org
wrote:
Am 19.10.2010 12:07, schrieb Alexander Klenin:
I personally wanted to do some things for FPC (although Unicode was
not one of them),
but hesitated, because the
On Tue, Oct 19, 2010 at 22:41, Florian Klaempfl flor...@freepascal.org wrote:
Am 19.10.2010 12:07, schrieb Alexander Klenin:
I personally wanted to do some things for FPC (although Unicode was
not one of them),
but hesitated, because the current code is too messy and fragile to touch,
In
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
1) I have serious suspicions that compile time on modern processors
is dominated by linking and I/O.
At least this is certainly true for FPC on Windows case.
Do you remember the factor 10 compiling speed advangage of Delphi7
On Wed, Oct 20, 2010 at 01:30, Martin Schreiber mse00...@gmail.com wrote:
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
1) I have serious suspicions that compile time on modern processors
is dominated by linking and I/O.
At least this is certainly true for FPC on Windows case.
Hi,
i know that in a Release Candidate stage is difficult or not appropriate
to make big changes, but the http://bugs.freepascal.org/view.php?id=17664
is a trivial one.
In the initialization section of the ibase60.inc, is missing the const
'fbembedlib' of the library name for the default
Am 19.10.2010 14:38, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 23:02, Florian Klaempfl flor...@freepascal.org
wrote:
Am 19.10.2010 13:54, schrieb Alexander Klenin:
from fixing case and reformatting of Math unit
This does not help anybody ;)
See, you have already rejected it ;-)
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt
mich...@freepascal.org wrote:
2) I'd say that at least half of his mistakes could be avoided
by better code structure of FPC -- he was really uncomfortable
using strange records and pchars instead
On Tuesday, 19. October 2010 16.42:19 Alexander Klenin wrote:
Do you remember the factor 10 compiling speed advangage of Delphi7
compared with FPC 2.4?
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html
I do. I also remember that one of the goals of DoDi's previous
On 19/10/10 15:42, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:30, Martin Schreibermse00...@gmail.com wrote:
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
1) I have serious suspicions that compile time on modern processors
is dominated by linking and I/O.
At least this
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
mich...@freepascal.org wrote:
What can be optimized, must be optimized.
Sorry, but does not this sound slightly exaggerated? :-)
2) I may believe that records are faster then classes,
but if they are faster then objects, then this is a
On Tuesday, 19. October 2010 17.17:04 Graeme Geldenhuys wrote:
Op 2010-10-19 17:06, Martin Schreiber het geskryf:
core aware compiler without a team of highest skilled fulltime developers
working several years...
Why do you think we are not that already? :-)
Aha! Maybe that's the reason
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
mich...@freepascal.org wrote:
What can be optimized, must be optimized.
Sorry, but does not this sound slightly exaggerated? :-)
2) I may believe that records are faster then classes,
but if
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
mich...@freepascal.org wrote:
If you need more convincing: the contnrs unit contains 2 hash classes.
one based on ansistrings, one with pchars and shortstrings. The pchar
version is easily 20% faster. It comes from the compiler code and was
On 2010-10-19 19:38, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
mich...@freepascal.org wrote:
If you need more convincing: the contnrs unit contains 2 hash classes.
one based on ansistrings, one with pchars and shortstrings. The pchar
version is easily 20%
Am 19.10.10 15:40, schrieb Alexander Klenin:
I fully understand that the reason for degrading the code structure
was efficiency.
I just doubt that it was/is a good trade-off.
Dear FPC Team,
After finishing porting the bullet physics library from C++ to FPC in the
last 2 months
Alexander Klenin пишет:
Ok, I went ahead and have taken look at the code.
I assume you speak about TFPHashList vs TFPCustomHashTable.
The classes are not really comparable, because they use quite
different internal data structures.
So instead I converted TFPHashList list to use ansistrings.
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
mich...@freepascal.org wrote:
If you need more convincing: the contnrs unit contains 2 hash classes.
one based on ansistrings, one with pchars and shortstrings. The pchar
version is easily 20%
On Tue, 19 Oct 2010, Sergei Gorelkin wrote:
Alexander Klenin пишет:
Ok, I went ahead and have taken look at the code.
I assume you speak about TFPHashList vs TFPCustomHashTable.
The classes are not really comparable, because they use quite
different internal data structures.
So instead I
Michael Van Canneyt пишет:
I believe it's not ShortStrings per se to blame, but storing them in a
large single memory block as it is being done in TFPHashList. Adding a
lot of keys will cause many reallocations. Large size of the block
forces memory manager to use variable-size pool, which
In our previous episode, Sergei Gorelkin said:
Average string length 45 characters:
ShortString: 12.0 s
AnsiString: 3.2 s
I agree that the first case is more relevant for the compiler,
but still you can see that ShortStrings are clearly not always faster.
I believe it's not
Am 19.10.2010 16:42, schrieb Alexander Klenin:
On Wed, Oct 20, 2010 at 01:30, Martin Schreiber mse00...@gmail.com wrote:
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
1) I have serious suspicions that compile time on modern processors
is dominated by linking and I/O.
At least
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote:
Hi,
Florian mentioned that the compiler is well tested, and I can see there are
many .pp files in the src/tests/ hierarchy.
Where would I look for the RTL and FCL unit tests? Is it the code in
src/tests/test/units/fpcunit/? If so, is that all
Marco van de Voort wrote:
Hello,
We have placed the first release-candidate of the Free Pascal Compiler
version 2.4.2 on our ftp-servers.
You can help improve the upcoming 2.4.2 release by downloading and
testing this release. If you want you can report what you have done here:
On Tuesday 19 October 2010 14:44:38 Florian Klaempfl wrote:
Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
First Pascal-like languages and later C.
FPC's main developer doesn't see a need for it.
Indeed. Please tell what a C front end to FPC helps? FPC has no
advantage over existing
Martin Schreiber schrieb:
This is a typical showcase for the premature micro-optimization --
for a few percentages of speed in the short term,
you pay in reduced code maintainability,
which precludes high-level optimizations in the long term.
IIRC one of the goals are to enable muti threaded
Florian Klaempfl schrieb:
and refactorings are not welcome.
Who says this? Usefull refactoring *is* welcome.
Umm, please specify what you understand by refactoring.
Something that does not move code around, or into new subroutines?
Something that can be achieved in a sequence of only
Florian Klämpfl schrieb:
Well, DoDi is not willing to fix the flaws of his patches so they were
rejected, see e.g.: http://bugs.freepascal.org/view.php?id=17584
You're kidding. The same result in a branch, with intermediate steps,
would be rejected as well (NoGlobal branch). Why break one
Florian Klaempfl schrieb:
Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
First Pascal-like languages and later C.
FPC's main developer doesn't see a need for it.
Indeed. Please tell what a C front end to FPC helps? FPC has no
advantage over existing C compilers except being a pascal
Alexander Klenin schrieb:
Actually, I certainly think (and hope) that DoDi's goal is _not_ a C frontend,
but to find _any_ possible venue to upgrade the code structure of FPC code.
Well - both ;-)
I would like to see my C parser working as an FPC front-end, instead of
producing intermediate
84 matches
Mail list logo
