Hi,
I read something funny on the python ML
request ...
but the syntax-sugar difference is small enough to make it no
big deal, anyway.
comp.lang.python's volume has (I'd guess) a 20%-30% component
of "suggestions for alleged improvements to the Python language"
(in all flavors, most often "cri
Dariusz Mazur escribió:
This is not problem to have separate executable, only have one source
to both GUI.
I made program which can work as desktop and as web-based (FCGI or
standalone web server)
Each form is create dynamical in runtime, source is one, but in
compile time:
1 for desktop: clasi
Graeme Geldenhuys escreveu:
2009/9/17 Luiz Americo Pereira Camara :
RTLString would not meant to be used in client applications. Would be useful
only in functions that interact with system calls like the RTL ones having
two benefits: avoiding extra encoding conversions and the need for
duplic
On 17 Sep 2009, at 17:52, Lukas Zeller wrote:
In the meantime I tested the supersimple test program that reliable
crashes on 10.6 also on a 10.5 installation.
Now here it behaves correctly (?!)
HOWEVER, with the original, big program the problem also shows on
10.5.
As I discovered another
2009/9/17 Luiz Americo Pereira Camara :
>
> RTLString would not meant to be used in client applications. Would be useful
> only in functions that interact with system calls like the RTL ones having
> two benefits: avoiding extra encoding conversions and the need for
> duplicated RTL (UTF16 and UTF8
Graeme Geldenhuys escreveu:
Luiz Americo Pereira Camara het geskryf:
Yes. RTLString would be just an alias to UnicodeString in win32 and
UTF8String in unixes
Bad news for Michael. :-) We would have to have serious documentation on
all the string types supported by FPC - I'm loosing cou
On 17 Sep 2009, at 17:28, Lukas Zeller wrote:
Now Snow Leopard 10.6.1, but we have a parallel installation on
Leopard 10.5.latest that also shows the problem.
Note that on Mac OS X 10.6.x (or rather with Xcode 3.2, which ships
with Mac OS X 10.6) there is a known linker bug that messes up
Hi Jonas,
A quick followup:
In the meantime I tested the supersimple test program that reliable
crashes on 10.6 also on a 10.5 installation.
Now here it behaves correctly (?!)
HOWEVER, with the original, big program the problem also shows on 10.5.
As I discovered another side effect (garbled
Hi Jonas,
On Sep 17, 2009, at 16:20 , Jonas Maebe wrote:
I am using FPC 2.2.4 on Mac OS X and the problem happens there.
On which version of Mac OS X?
Now Snow Leopard 10.6.1, but we have a parallel installation on
Leopard 10.5.latest that also shows the problem.
And in fact it was -
I'll try that ASAP :)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 17 Sep 2009, at 16:16, Lukas Zeller wrote:
Which FPC version are you using? I fixed shared library
initialisation/finalisation for Mac OS X and Linux in FPC 2.2.4.
I am using FPC 2.2.4 on Mac OS X and the problem happens there.
On which version of Mac OS X?
And in fact it was - while r
Hello Jonas,
thanks for responding so quickly!
On Sep 17, 2009, at 11:50 , Jonas Maebe wrote:
On 17 Sep 2009, at 11:33, Lukas Zeller wrote:
I guess I really need to understand how the FPC runtime expects to
be initialized when located in a shared lib, but I couln't find any
hint so far in
Hi,
thank you for your very fast answers.
Joost, I had an application that worked as GUI (my boss likes GUI), then
my colleagues asked me for a command line and my boss asked for a CGI...
I resulted in 3 separate projects which is impossible to maintain -I'm
not well enough organized. So I wanted
Felipe Monteiro de Carvalho schreef:
On Thu, Sep 17, 2009 at 9:42 AM, Jonas Maebe wrote:
It isn't. It is a string type whereby the string encoding is part of the
string information (just like the reference count and length already are
currently).
Ah, that string type. Previous discussions bet
On Thu, Sep 17, 2009 at 9:42 AM, Jonas Maebe wrote:
> It isn't. It is a string type whereby the string encoding is part of the
> string information (just like the reference count and length already are
> currently).
Ah, that string type. Previous discussions between Lazarus developers
concluded t
Gilles MARCOU pisze:
Hello,
I'm trying to build an interface for a program so that it could be used
as a command line, a GUI or a CGI. For the CGI, I use powutils 1.7.1,
FPC 2.2.0 and Lazarus 0.9.24. I mean that the same executable should be
used either as a CGI, a command line or a GUI.
Curren
In our previous episode, Graeme Geldenhuys said:
> >>
> > http://www.stack.nl/~marcov/unicode.jpg
>
> The electronic version is also freely available from the unicode.org
> website. I can't remember the direct link, but I do have Unicode v5
> chapters 1-6 here in pdf format, downloaded from unicod
Vincent Snijders het geskryf:
>>
> http://www.stack.nl/~marcov/unicode.jpg
The electronic version is also freely available from the unicode.org
website. I can't remember the direct link, but I do have Unicode v5
chapters 1-6 here in pdf format, downloaded from unicode.org
Regards,
- Graeme -
On 17 Sep 2009, at 13:34, Felipe Monteiro de Carvalho wrote:
On Thu, Sep 17, 2009 at 8:11 AM, Jonas Maebe > wrote:
Please, not again this discussion. I think we all know what
everyone thinks
about that, what the pitfalls are and this will eventually be
solved by
D2009-style unicode string s
You can test this also using the TCharacter class
http://wiki.lazarus.freepascal.org/Theodp
procedure TForm1.Button1Click(Sender: TObject);
var a,b,c:String;
begin
a:= UTF8Encode(WideChar($41)+WideChar($030A)); //Decomposed Å
b:= UTF8Encode(WideChar($212B)); //Å Ångström
c:= UTF8Encode(WideChar(
Michael Schnell het geskryf:
>
> How am I supposed to input o + " in Open Office in a way that the
> program combines them to ö ?
Not that this is the right list for OpenOffice support - but I'll make
it quick. ;-)
I use Dvorak keyboard layout, so it makes such character input a breeze.
Alterna
Graeme Geldenhuys wrote:
> What I meant was, use OpenOffice to open a document with Unicode text in
> it. Make use that some "visual" character and bases on normalized text
> and some are bases on non-normalized text (two or more characters
> forming one visual character. eg: o + ¨ = ö).
How am I
On Thu, 2009-09-17 at 11:50 +0200, Gilles MARCOU wrote:
> Hello,
>
> I'm trying to build an interface for a program so that it could be used
> as a command line, a GUI or a CGI. For the CGI, I use powutils 1.7.1,
> FPC 2.2.0 and Lazarus 0.9.24. I mean that the same executable should be
> used eith
On Thu, Sep 17, 2009 at 8:11 AM, Jonas Maebe wrote:
> Please, not again this discussion. I think we all know what everyone thinks
> about that, what the pitfalls are and this will eventually be solved by
> D2009-style unicode string support.
AFAIK D2009-style solution is just a reference counted
Gilles MARCOU het geskryf:
> I'm trying to build an interface for a program so that it could be used
> as a command line, a GUI or a CGI. For the CGI, I use powutils 1.7.1,
> FPC 2.2.0 and Lazarus 0.9.24. I mean that the same executable should be
> used either as a CGI, a command line or a GUI.
I
Michael Schnell het geskryf:
>
> Unfortunately I don't have a language independent version of Open
> Office, that would be able to do this for -say- ancient Egypt.
What I meant was, use OpenOffice to open a document with Unicode text in
it. Make use that some "visual" character and bases on norma
On 17 Sep 2009, at 13:11, Graeme Geldenhuys wrote:
fpGUI Toolkit is in the same boat. Using UTF-8 inside AnsiStrings. And
like Lazarus, fpGUI also has various UTF-8 friendly RTL String
functions. It works relatively well, as long as the developer knows
that
he/she must rather use the Unicode
Michael Schnell het geskryf:
> Marco van de Voort wrote:
>
>> like Lazarus UTF-8 in
>> ansistring.
>
> That already produced a huge confusion and obviously is a way that can't
> decently be followed in the future.
fpGUI Toolkit is in the same boat. Using UTF-8 inside AnsiStrings. And
like Lazaru
Did you find / define a Widget set that is compatible for a local GUI
and a GCI that is supposed to be connected via HTML ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hello,
I'm trying to build an interface for a program so that it could be used
as a command line, a GUI or a CGI. For the CGI, I use powutils 1.7.1,
FPC 2.2.0 and Lazarus 0.9.24. I mean that the same executable should be
used either as a CGI, a command line or a GUI.
Currently I have kept separat
In our previous episode, Michael Schnell said:
> Marco van de Voort wrote:
> >
> > http://www.stack/nl/~marcov/unicode.jpg
> >
>
> Obviously a huge Volume for a huge encoding scheme that really imposes a
> huge number of huge problems ;).
No, the description is about one-two hundred pages, the
On 17 Sep 2009, at 11:33, Lukas Zeller wrote:
I guess I really need to understand how the FPC runtime expects to
be initialized when located in a shared lib, but I couln't find any
hint so far in the FPC docs nor in the list archives.
Which FPC version are you using? I fixed shared library
Marco van de Voort wrote:
> like Lazarus UTF-8 in
> ansistring.
That already produced a huge confusion and obviously is a way that can't
decently be followed in the future.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists
Graeme Geldenhuys wrote:
>
> Open a document with OpenOffice and search for text.
Unicode is all about language independent coding.
Unfortunately I don't have a language independent version of Open
Office, that would be able to do this for -say- ancient Egypt.
-Michael
Marco van de Voort wrote:
>
> http://www.stack/nl/~marcov/unicode.jpg
>
Obviously a huge Volume for a huge encoding scheme that really imposes a
huge number of huge problems ;).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http:/
Hello,
I already dug through the archives but found nothing really related to
a weird problem I have with a FPC shared lib which is used by a C
shared lib which in turn is a plugin to a C main program.
The net effect is that the FPC library crashes (apparently when trying
to allocate a FP
In our previous episode, Graeme Geldenhuys said:
> > A good place to start:
> >
> > http://www.stack.nl/~marcov/delphistringtypes.txt
>
> Good god! 16 different types already! It's worse (and a lot more) than I
> thought. :-)
Not counting aliases and untyped library level usage like Lazarus UTF-
Marco van de Voort het geskryf:
>
> A good place to start:
>
> http://www.stack.nl/~marcov/delphistringtypes.txt
Good god! 16 different types already! It's worse (and a lot more) than I
thought. :-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http:
In our previous episode, Marco van de Voort said:
> Java is not portable. The VM hides the platform differences.
Maybe that came out to strong. I don't want endless discussions about this.
Point is, I meant more "Java has a different philosophy wrt portability".
__
In our previous episode, Graeme Geldenhuys said:
> >
> > Yes. RTLString would be just an alias to UnicodeString in win32 and
> > UTF8String in unixes
>
> Bad news for Michael. :-) We would have to have serious documentation on
> all the string types supported by FPC - I'm loosing count! We woul
Luiz Americo Pereira Camara het geskryf:
>
> Yes. RTLString would be just an alias to UnicodeString in win32 and
> UTF8String in unixes
Bad news for Michael. :-) We would have to have serious documentation on
all the string types supported by FPC - I'm loosing count! We would
also need a nice b
Michael Schnell het geskryf:
>> Neither that much space nor that much time is required.
>
> Any pointers regarding a decent estimation ?
Open a document with OpenOffice and search for text. It's as simple as
that. You are seriously over exaggerating on the GBytes size lookup
tables etc...
Maybe
http://www.stack/nl/~marcov/unicode.jpg
http://www.stack.nl/~marcov/unicode.jpg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
In our previous episode, Michael Schnell said:
[ Charset ISO-8859-1 unsupported, converting... ]
> Jonas Maebe wrote:
> >
> > Neither that much space nor that much time is required.
>
> Any pointers regarding a decent estimation ?
http://www.stack/nl/~marcov/unicode.jpg
there is a v5 now though
On 17 Sep 2009, at 09:55, Michael Schnell wrote:
Jonas Maebe wrote:
Neither that much space nor that much time is required.
Any pointers regarding a decent estimation ?
No.
As there are billions of possible Unicode "characters" and most of
them
potentially can be alternately depicted
> This is an ARM system so it should support Mono. There is a Huge list of
> (free and commercial) languages that support MONO, including Object
> Pascal: Delphi Prism.
Let's see:
Individual developers (1 year):
* iPhone dev program: 100 USD
* Mono touch: 400 USD
* Delphi Prism: 500 USD
Tota
Jonas Maebe wrote:
>
> Neither that much space nor that much time is required.
Any pointers regarding a decent estimation ?
As there are billions of possible Unicode "characters" and most of them
potentially can be alternately depicted by one or multiple
multi-Unicode surrogates, I don't share
On 17 Sep 2009, at 09:33, Michael Schnell wrote:
Of course I have been supposing that (if possible) the RTL would
call a
library function. But it makes no difference: If the algorithm to
"normalize" the multi-character codes (if this is possible at all)
needs
a table of several GBytes and C
ABorka wrote:
> I think many
> people/companies would happily pay the price to have some nice language
> for development.
This is an ARM system so it should support Mono. There is a Huge list of
(free and commercial) languages that support MONO, including Object
Pascal: Delphi Prim.
-Michael
___
Jonas Maebe wrote:
> The way to implement stuff like that is to call the appropriate library
> functions. It makes no sense to completely re-implement everything in
> the RTL.
Of course I have been supposing that (if possible) the RTL would call a
library function. But it makes no difference: If t
50 matches
Mail list logo
