[MSEide-MSEgui-talk] Betriebsausflug

24. 8. Mit freundlichem Gruß Michael Schnell - Software-Entwicklung - [cid:image001.png@01D9A51A.FD7F4750]<https://www.lumino.de/> LUMINO Licht Elektronik GmbH, Germany Europark Fichtenhain A8, D-47807 Krefeld fon: +49 (2151) 8196-172 fax: +49 (2151) 8196-272 mschn...@lumino.de<mai

Re: [MSEide-MSEgui-talk] Destiny of Martin's projects

> > but what is "code aware strings" ? The Delphi XE, a "code aware string type" can be defined to hold different types of Data by adding a number in parentheses to the "string word in the definition. E.g. "TMyString = String(CP_ACP)"; there is a definition CP_ACP = 0; meaning default ANSI

Re: [MSEide-MSEgui-talk] Destiny of Martin's projects

> > Please, take a look at this picture: > > > This shows that it can do Unicode, bit not that it does code aware strings. -Michael ___ mseide-msegui-talk mailing

Re: [MSEide-MSEgui-talk] Destiny of Martin's projects

Ø Java faster than C++ ? If a language running in a Framework is the fastest, seemingly the high-speed stuff can be handled by the Framework itself. So you also could try C# / .NET / Mono And if you want to do Pascal Oxygen / RemObjects “Elements” -Michael

Re: [MSEide-MSEgui-talk] Destiny of Martin's projects

> What about to test it by yourself ? ;-) Test I would just read the documentation ;) ;) ;) -Michael ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] Destiny of Martin's projects

> > Does it really feature coding aware strings ? > > I am not sure to understand what you ask. > In new Delphi and fpc versions, strings are "code aware": e.g. you can define a string to hold a dedicated character encoding. E.g.: "MyANSI_String: String(CP_ACP);" to define that this variable

Re: [MSEide-MSEgui-talk] Destiny of Martin's projects

> -Ursprüngliche Nachricht- > Von: fredvs > Gesendet: Dienstag, 5. Februar 2019 12:37 > An: mseide-msegui-talk@lists.sourceforge.net > Betreff: Re: [MSEide-MSEgui-talk] Destiny of Martin's projects > > > Does it really feature coding aware strings ? > > I am not sure to understand

Re: [MSEide-MSEgui-talk] Destiny of Martin's projects

> MSElang has already implemented {$mode pascal} (similar as objfpc) and > {$mode mselang} (similar to objfpc + some Oberon flavor). > That is interesting, indeed ! Does it really feature coding aware strings ? I had been discussing this with Martin some two years ago. We agreed that the way

Re: [MSEide-MSEgui-talk] Destiny of Martin's projects

> Martin was too much humble. His mselang project is already very far. Can MSEGUI be compiled using MSELang ? I would be surprised, as Martin did not intend to make MSELang very compatible to fpc. E.g. he did not want to implement "new strings" and other "Delphi oddities". -Michael

Re: [MSEide-MSEgui-talk] Rich internet Application

On 18.12.2017 22:49, Graeme Geldenhuys wrote:  Web apps users have different needs and expect different behaviour to desktop applications. Not in my world :-). Same consists of embedded software that most of the time does not need any GUI at all. But usually a network connection is available.

Re: [MSEide-MSEgui-talk] Rich internet Application

On 18.12.2017 10:29, Martin Schreiber wrote: AFAIK it does not support interfaces nor pointers. Why not use one of the many javascript frameworks instead? Ifi provides the native visual components provided by mseGUI so you can do a project and switch between local and remote GUI without

Re: [MSEide-MSEgui-talk] Rich internet Application

On the fpc mailing list: On 16.12.2017 17:36, Michael Van Canneyt wrote: Hello fellow Pascal enthousiasts, It is with great pleasure that I can finally announce the first publicly available version of pas2js. A "beta" version, version 0.8.39. ... pas2js is a Object Pascal to Javascript

[MSEide-MSEgui-talk] Rich internet Application

Hi mse community, Do you monitor the thread "Re: [Lazarus] Quick Video: A Web Application" in the Lazarus mailing List,  saying: "Normally, early december a RC version of pas2js will be released. pasjs currently is more or less at the level of D7 compatibility (minus interfaces and pointers)

Re: [MSEide-MSEgui-talk] Some question about MSE thread...

On 28.07.2017 19:51, Fred van Stappen wrote: Huh, ... , and do you think it could be possible to compile a fpGUI app with mse console ? Something similar this is what tried some years ago (with some help from Martin)ad gave up -Michael

Re: [MSEide-MSEgui-talk] Some question about MSE thread...

On 28.07.2017 13:20, Fred van Stappen wrote: >> Not easy, it needs the MSE-infrastructure. > Been there, gave up. :) :) :) Hello Martin. So, it would not be possible to create a console application using MSE MSE-infrastructure ? Other than with Lazarus, AFAIK, mse allows for full blown

Re: [MSEide-MSEgui-talk] Some question about MSE thread...

Anyway, I misread the post by Martin you replied to. He said ".. wait *on* main thread... " and not ".. wait *in* main thread... " So the queue is irrelevant on that behalf and you can use a semaphore or e.g. do a poll-loop that includes sleep(). -Michael

Re: [MSEide-MSEgui-talk] Some question about MSE thread...

On 27.07.2017 22:23, Fred van Stappen wrote: > Do you wait on the main thread in worker thread in some way or another? Huh, maybe... (but could you give some code of what you propose so I can check it ?) IMHO, "waiting" in the main thread is "forbidden". So the Audio Thread should post an

Re: [MSEide-MSEgui-talk] Some question about MSE thread...

On 16.07.2017 07:32, Martin Schreiber wrote: TMSEthread.Queue > ? application.postevent(). Often application.lock()/unlock() is more convenient. This is a decent way in the mse-world, as here you supposedly always have a full blown "application" (even "nonGUI"), while in Lazarus only

Re: [MSEide-MSEgui-talk] Some question about MSE thread...

On 16.07.2017 07:32, Martin Schreiber wrote: Not easy, it needs the MSE-infrastructure. Been there, gave up. :) :) :) -Michael -- Check out the vibrant tech community on one of the world's most engaging tech sites,

Re: [MSEide-MSEgui-talk] Variant part in MSElang objects

On 06.06.2017 13:12, Martin Schreiber wrote: Because case in records is crap. It misleadingly pretends that there is access type control by the tags and it is clumsy. Right you are. But it never had been different in Pascal :( -Michael

Re: [MSEide-MSEgui-talk] Variant part in MSElang objects

On 04.06.2017 06:21, Martin Schreiber wrote: Yes, and the replacement of "case" in pascal records. Why introduce a completely new notation instead of just stay with "case" ? This would be rather obvious in Pascal. -Michael

Re: [MSEide-MSEgui-talk] WebAssembly

On 16.03.2017 07:40, Martin Schreiber wrote: > That could be possible but it is not "standard", which means nobody > will use it. Hmm. I did not at all think about any "standard" (meaning the providers of the two parts being different companies). In the parsed few years, I came across several

[MSEide-MSEgui-talk] WebAssembly

Did you see this ? On Sat, 11 Mar 2017, Daniel Gaspary wrote: Hi, Is there something planned in this matter for FPC? I was reading about the new Firefox making WebAssembly publicly available ("On Tuesday Firefox 52

Re: [MSEide-MSEgui-talk] [fpc-pascal] polYdev release 1.0 with fpc as superstar.

On 26.09.2016 11:11, Graeme Geldenhuys wrote: > As I'm a FreeBSD user for some years, > I'm also very happy Fred used FreeBSD as the base for his distro. > So maybe you could comment on a question that cam in my mind: AFAIK, Mac OS is based on BSD, so APIs should not be to different from

Re: [MSEide-MSEgui-talk] [fpc-pascal] polYdev release 1.0 with fpc as superstar.

> Fred did announce it here too. There is a post about it - last week > Wednesday (17:25 GMT). So I'm sorry for the unnecessary traffic. Astonishingly, s announcement did not gain any attention, though. -Michael --

Re: [MSEide-MSEgui-talk] [fpc-pascal] polYdev release 1.0 with fpc as superstar.

Did you see this ? -Michael On 21.09.2016 18:33, fredvs wrote: > Hello. > > polYdev release 1.0 is ready to download. > > polYdev is a multiarch FreeBSD 10.3 operating system. > > Thanks to his emulators, polYdev is able to compile and run applications for > FreeBSD 64/32, Linux 64/32 and

Re: [MSEide-MSEgui-talk] Win 10 IOT Core

On 10/19/2015 05:46 PM, Martin Schreiber wrote: > Probably if you write a DirectX backend. Are there mouse/touch and > keyboard events available? How works window management? In fact I have no idea about the API of DirectX. I once used it with Delphi via SDL. Whether and how complete DirectX is

[MSEide-MSEgui-talk] Win 10 IOT Core

We were just discussing this in the Lazarus mailing list (see thread with the same caption). It might be interesting here, as well: I understand that Microsoft on the long run will try to have the Wince (and WinPhone ?) users to upgrade to the Windows 10 product line. I understand that with

Re: [MSEide-MSEgui-talk] Produced code of MSElang and FPC

On 03/24/2015 01:04 PM, Martin Schreiber wrote: No, MSElang has its own optimised binary represention for the unified record, As you might have read, in the FPC list I suggested exactly this just this morning :-) -Michael

Re: [MSEide-MSEgui-talk] First comparison MSElang - FPC ;-)

On 01/25/2015 07:32 PM, Ivanko B wrote: How about the Promise conseption for task parallelizing/waiting as a benifitiar of multiple cores? How is this related to the future notation used in Delphi Prism (aka Oxygen )? -Michael

Re: [MSEide-MSEgui-talk] MSElang, status

On 12/03/2014 02:21 AM, Marcos Douglas wrote: If I understood right, your team still working with Delphi but for new code they are using FPC and these codes need to work on Delphi and FPC, right? They are not at all working with fpc (and hardly know what exactly fpc is) . But it would make a

Re: [MSEide-MSEgui-talk] MSElang, status

On 12/03/2014 01:38 PM, Marcos Douglas wrote: I hope to FPC team forget Delphi and follow your own way. There is no fpc team. The only goal is porting the huge project to Linux. A complete re-implementation is not possible (worth some 50 man-years) -Michael

Re: [MSEide-MSEgui-talk] MSElang, status

On 11/28/2014 05:56 PM, Marcos Douglas wrote: But if you can use FPC why not migrate all? Why use Delphi compiler on Windows and FPC for others? The migration Delphi - fpc would take at lease a year, including several third-party components (for multiple developers). In that time they need to

Re: [MSEide-MSEgui-talk] MSElang, status

On 11/27/2014 01:02 PM, Marcos Douglas wrote: I don't understand why so much discussion about Unicode support on FPC list Did you read http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support ? Here: With Delphi XE, Embarcadero decided that the

Re: [MSEide-MSEgui-talk] MSElang, status

On 11/28/2014 03:20 PM, Marcos Douglas wrote: The problem in FPC, I think, is they want to keep Old code, Delphi compatibilities, implement new things... at the same time! Plus creating code for multiple OSes and processors. IMHO they should: 1- Forget Delphi compatibilities, at least in mode

Re: [MSEide-MSEgui-talk] MSElang, status

On 11/28/2014 04:04 PM, Martin Schreiber wrote: Please forget the crap with codepage aware ansistring, dynamic encoded string and what not... IMHO, the reference counting element-size and encoding-brand enabled (tm) data type is a really powerful concept. But unfortunately there is no decent

Re: [MSEide-MSEgui-talk] MSElang, status

On 11/28/2014 04:23 PM, Marcos Douglas wrote: If wants Delphi so, buy and use it! It still is not usable on Linux (and supposedly VCL applications will never be portable to Linux with Delphi). fpc can help. :-( In fact my colleagues need to keep their huge set of huge Programs compilable by

Re: [MSEide-MSEgui-talk] compiling mseide-msegui on ARMHF

On 11/12/2014 12:06 PM, Martin Schreiber wrote: Now we need to fix MSEide-ARM. I just got a Raspberry pi but it does not work so you need to debug MSEide youself. IMHO, in this class of devices, as well Odroid as BeaglerBone are much more interesting than Raspberry pi. So don't forget to test

Re: [MSEide-MSEgui-talk] compiling mseide-msegui on ARMHF

On 11/12/2014 01:40 PM, Martin Schreiber wrote: AFAIK you have a BeagleBone, please test MSEide+MSEgui on that device. Sorry. I don't have one. I do have colleagues who have BeagleBones and who have Odroids. -Michael

Re: [MSEide-MSEgui-talk] Windows Service Application support

On 10/02/2014 08:59 AM, Graeme Geldenhuys wrote: Thanks, but I need an actual Windows Service Application The Windows Service and Linux Daemon Applications would greatly benefit from being Event Driven. This could easily be done by basing them on NoGUI. -Michael

Re: [MSEide-MSEgui-talk] Windows Service Application support

On 10/02/2014 07:25 AM, Martin Schreiber wrote: MSEgui supports event driven non-GUI applications. We have been discussing this since years ;-) . The (strictly closed) TThread implementation in the fpc RTL prevents an (easy) implementation of this (i.e. without creating a second Event Queue

Re: [MSEide-MSEgui-talk] General

On 08/20/2014 09:04 PM, Michael wrote: 1. Issue a short description of (nearly) each component (widget), describing its major functions and features. 2. Provide more simple programm samples, showing the functionality of the software (e.g. MDI, embedded forms, skinning, database, etc.). Please

Re: [MSEide-MSEgui-talk] MSElang, long strings and dynamic arrays are not thread safe

On 05/11/2014 10:50 AM, Martin Schreiber wrote: Have you ever concurrentely read strings from different threads? I do this all the time. -Michael -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For

Re: [MSEide-MSEgui-talk] MSElang, long strings and dynamic arrays are not thread safe

On 05/11/2014 08:06 AM, Martin Schreiber wrote: Hi, Because of the big overhead by locked refcount operations and memory barriers long strings and dynamic arrays are not thread safe, even reading needs serializing if the data will be accessed from several threads. In exactly what environment

Re: [MSEide-MSEgui-talk] MSElang, long strings and dynamic arrays are not thread safe

On 05/12/2014 10:40 AM, Martin Schreiber wrote: AFAIK memory barriers are extremely evil. Of course with modern CPUs this is correct. Anyway, not allowing normal seemingly innocent language types for ubiquitous use asks for an infinite count of problems. -Michael

Re: [MSEide-MSEgui-talk] MSElang, long strings and dynamic arrays are not thread safe

On 05/12/2014 11:02 AM, Martin Schreiber wrote: Managed types apparently are not innocent. ;-) That is obviously for language developers. But to the language users thy seem to innocent ;-) -Michael -- Accelerate Dev

Re: [MSEide-MSEgui-talk] MSELang heretic ideas

On 01/06/2014 01:00 PM, Martin Schreiber wrote: with l:lab1 do l.left:= 10; l.top:= 20; end; I do like the quoted with as same eliminates the ambiguity that is inheritant to with (hiding part of the namespace of outer with, the class and globals). To me with l:=lab1 would be more logical as

Re: [MSEide-MSEgui-talk] MSELang heretic ideas

On 01/07/2014 08:17 AM, Ivanko B wrote: in pascal you can't write functions with variable number of arguments AFAIK, C uses va_list lfor that. Yep. I use it a lot. (Important for C: there is a corresponding concept and syntax in Macros that supports this. ) In Pascal we have the concept of

Re: [MSEide-MSEgui-talk] MSELang heretic ideas

On 01/07/2014 12:07 PM, Martin Schreiber wrote: The first step of := is :. ;-) Nice !:-) :-) :-) -Michael -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/17/2013 08:24 PM, Sieghard wrote: What's so special about abs? Nothing at all. It's simply a comparison .. abs() looks like a function but in fact it isn't. So it's a very special kind of function (at least it is similar to a set of overloaded function or a kind of generic). In Pascal

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/17/2013 08:24 PM, Sieghard wrote: BUT: Does anybody _really_ think that type casting _does_ something? In fact it does stuff like zero or sign extend or cut away high order bits. -Michael -- Rapidly troubleshoot

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/17/2013 06:52 PM, Martin Schreiber wrote: integervar:= abs(integer(cardinalvalue)); but for cardinalvalue = $ cardinalvalue = chard32 (abs(integer(cardinalvalue))); would result in 1, while cardinalvalue = abs (cardinalvalue) in fpc would result in $ -Michel

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/17/2013 07:23 PM, Martin Schreiber wrote: BTW, Free Pascal has no unsigned abs(). http://www.freepascal.org/docs-html/rtl/system/abs.html Did anybody test what fpc really does for cardinalvalue = abs (cardinalvalue); with cardinalvalue = $ ? -Michael

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/18/2013 10:26 AM, Julio Jiménez wrote: Not true. You can find it in stdlib.h This is not C (language) but a library. -Michael -- Rapidly troubleshoot problems before they affect your business. Most IT

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/18/2013 10:36 AM, Julio Jiménez wrote: Abs in pascal is also in a library (System unit) is not part of the language Really ? I had the impression that it is a compiler builtin. -Michael -- Rapidly

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/18/2013 10:52 AM, Julio Jiménez wrote: You don't need to define abs in C, just use stdlib.h, this is what I wanted to say.. :) OK. But right now we are discussing concepts, not ease of use :-) . -Michael --

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/16/2013 03:58 PM, Martin Schreiber wrote: unsigned:= card32(abs(signed)); This suggests that the result of abs is signed and need an explicit conversion to unsigned. I'm not sure that this is beneficial. OTHO what is abs anyway ? Is it some kind of builtin overloaded function that

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/16/2013 04:44 PM, Ivanko B wrote: Then typecasts ABS should be inline-d. Typecast is not only inlined but even builtin (in C source code it not even looks like a function; this is PASCAL specific stuff.) abs() is a special beast, anyway... -Michael

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/17/2013 09:30 AM, Michael Schnell wrote: OTHO what is abs anyway ? Is it some kind of builtin overloaded function that works differently for different argument types ? BTW.: Funny stuff: Is the argument of abs() would be fixed to signed, and we would have automatic type conversion

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/16/2013 02:29 PM, Ivanko B wrote: unsigned := signed ? Here, user know what he/she wants to get No he does not. (absolute value of the signed). Even you don't :-) . If you do unsigned := signed; you get the correct positive value if positive. But if it is negative you'll get

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

On 12/16/2013 02:52 PM, Ivanko B wrote: But if it is negative you'll get maxunsigned + value + 1, as === Really it should do internally smth like : unsigned:= ABS(signed) -1 This would be different to any known language and much slower. -Michael

Re: [MSEide-MSEgui-talk] MSElang, implicit type conversions

+1 (even seemingly not a very common language restriction) -Michael -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/22/2013 06:25 PM, August Oktobar wrote: What about multiple return values (e.g. in Golang)? ... In effect making function results out variables. With that you also could vote for deamons (the previous value of the variable to be set by a function can be seen within a function, in

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/22/2013 06:52 PM, Ivanko B wrote: How looks the call of the function? == Smth like in Python: (var1,var2):= MultResFunc(arg1,arg2); In Python, the (var1,var2) syntax has other effects on it's own, as well IIRC, in a language I used some 100 years ago (called PLZ

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/25/2013 09:36 AM, Michael Schnell wrote: With that you also could vote for deamons (the previous value of the variable to be set by a function can be seen within a function, in effect making function results var variables. Sorry, this was incorrect. Daemons in this context

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/24/2013 08:44 AM, Martin Schreiber wrote: On Saturday 23 November 2013 21:23:11 Ivanko B wrote: := 'The string result: '+avalue; = := instead of exposing Result ? Looks interesting. It is mandatory and allowed as last statement only. I also think this is a nice idea.

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/24/2013 02:48 PM, Marcos Douglas wrote: But if 'return' exists, why I will use ':= value'??? Two ways to do the same? ...like in C ? return lvalue; might be a synonym for := lrvalue; return; -Michael -- Shape

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

.. or := lrvalue; exit; -Michael -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/24/2013 05:21 PM, Marcos Douglas wrote: I disagree that a program without 'return' or 'exit' uses a more safe coding style. +1; you often would need to use break and/or clumsy constructs using flags or even goto. IMHO, each of this makes the code less readable. -Michael

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/24/2013 05:41 PM, Ivanko B wrote: Also how about BREAK(nesting_level) NEXT(nesting_level) ? Some languages provide that and one is quite handy. Nesting levels are just horrible, as you will regularly forget to change them appropriately when you add a new nesting level to your code.

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/25/2013 10:43 AM, Martin Schreiber wrote: You and Marcos probably never had to debug code with common necessary cleanup at procedure end and a deeply nested sometimes triggered 'exit' which bypassed the cleanup accidentally. It happened several times to me... I do see the argument

Re: [MSEide-MSEgui-talk] MSElang, objects

While I think, private, protected and public are enough visibility complexity (omitting published and all the new fancy stuff invented by Embarcadero), I supposed abstract is one of the concepts that should be added to the description. -Michael

Re: [MSEide-MSEgui-talk] MSElang, objects

On 11/22/2013 09:09 AM, Michael Schnell wrote: I supposed abstract is one of the concepts that should be added to the description. + reintroduce (will non-heap objects have virtual methods ?) BTW.: IMO method is a more appropriate new combined name for procedure/function than sub

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/21/2013 05:41 PM, Ivanko B wrote: end:= result; == It means one more memory copying opetation which can be quite expensive in case of large data (dynarrays,..). Why does everybody suspect that Martin is a bad compiler designer that is unable to do decent

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/21/2013 08:24 PM, Ivanko B wrote: The 'sub' keyword is just ugly, not an error. ;-) = Feels less ugly than function for non-returning procedure for returning :) IMHO. If inventing a new keyword replacing as well function as procedure it should be Method as same

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/21/2013 10:50 PM, Sieghard wrote: Hallo Michael, Du schriebst am Thu, 21 Nov 2013 10:10:29 +0100: Using a procedure name without () can be either a call to this procedure or denote the address of this procedure to be moved onto a procedure variable. It will be what was defined for it

Re: [MSEide-MSEgui-talk] MSElang, objects

On 11/22/2013 10:54 AM, Martin Schreiber wrote: Doesn't 'method' imply that there is an instace pointer additional to the code address? For me this would be a method of object. (But of course this is a matter of taste.) -Michael

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/21/2013 12:38 AM, Sieghard wrote: How big is this C preprocessor ... The question is, how big is a full description :-) (without comments on how to use it :-) :-) :-) ). -Michael -- Shape the Mobile

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/21/2013 12:42 AM, Sieghard wrote: That's a rather silly statement. Can you describe an implementation of a jump table mechanism using non-constant positions for its entries? If or if not jump tables are used is up to the compiler. A case _syntax_ easily can be done with non-constants.

Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types

On 11/21/2013 01:03 AM, Sieghard wrote: the values you assign to the symbols (bit patterns, in this case) are just convention. And don't matter as long as no calculation can return a result outside of the base set. Yep. And for casting them to bigger types (also implicitly when doing

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/21/2013 07:31 AM, Martin Schreiber wrote: As usual I still don't understand. procedure strfunc(): msestring; begin return 'The string result'; end; Slight Advantage of Result: procedure strfunc(x: Boolean): msestring; begin Result := 'The string result'; if x then

Re: [MSEide-MSEgui-talk] MSElang, procedures and functions

On 11/20/2013 11:04 PM, Marcos Douglas wrote: No, no, no...please! :( I know that you want to make a language more ortogonal but exceptions could exist! If you do not have parameters, why I need use this '()'? This introdices is a well known ambiguity in Delphi, that in fpc is resolved (when

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/21/2013 10:06 AM, Martin Schreiber wrote: that semantic is independent of order of items. With variable case labels this is not possible. I don't understand what you mean by this. Could you give an example ? Of course non-constants lead to additional logical problems. If a case label

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/21/2013 10:47 AM, Martin Schreiber wrote: I don't think so. for me 'case' 'else if'. Don't you like compiler magic ? :-) -Michael -- Shape the Mobile Experience: Free Subscription Software experts and

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/20/2013 12:56 AM, Sieghard wrote: You got a funny gcc. Mine doesn't do any preprocessing itself, it needs to call an external program (named cpp) for that purpose. Where does your gcc come from? in fact this is seems to be wrong. Do cp -dumpecs and you will see that it's the

Re: [MSEide-MSEgui-talk] MSElang, compound statements

and cpp --help outputs ... -Xassembler argPass arg on to the assembler -Xpreprocessor arg Pass arg on to the preprocessor -Xlinker arg Pass arg on to the linker ... ??? -Michael -- Shape

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/21/2013 03:25 PM, Ivanko B wrote: gc = GNU C compiler g++ = GNU C++ compiler cpp = GNU C/C++ preprocessor among other stuff cpp dumpspecs outputs *link_emulation: elf_i386 This does make no sense at all for a preprocessor -Michael

Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types

On 11/19/2013 09:20 PM, Sieghard wrote: Yep. The highest order bit in a number in the 2's complement encoding is the sign bit. Ok, let's look at it this way. Then, what's the value of this lone sign bit? This is obvious. Take a look at the predecessor of zero as done by the algorithm any

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/19/2013 09:31 PM, Sieghard wrote: C doesn't really _have_ enumerated _types_. the compiler seems to think differently as he happily compiles: typedef enum claimUsage_e { LTE_CLAIM_SEM_MGT, LTE_CLAIM_SEM_BASE, LTE_VT_MGT, LTE_VT_BASE } LTE_claimUsage_e; -Michael

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/20/2013 12:56 AM, Sieghard wrote: _No_ language can make certain that a preprocessor cannot be used. It can make use of the preprocessor syntax itself (e.g. requiring a # at the start of a line for some purpose) _No_ language should depend on the use of a preprocessor. Right. You got

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/19/2013 02:52 PM, Martin Schreiber wrote: It is planned to unify record, object and class in a single concept. Nice and consequently thought out ! -Michael -- Shape the Mobile Experience: Free Subscription

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/19/2013 03:53 PM, Martin Schreiber wrote: case can. Having elseif looking like case is evil. I think the contrary: as well with case as with an elseif (or with pure fpc syntax: end else if ... then begin) cascade only one of the multiple alternatives is taken (other then with if test1

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/19/2013 06:38 PM, Ivanko B wrote: case can. But case: only accepts (compile time) contants in its labels so its usage is restricted. An improved language could do away with this rather silly restriction -Michael

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/20/2013 01:23 AM, Sieghard wrote: They've been just resently removed from Delphi. They were called objects, Objects are not constant but more like static classes. And in fact they have not been removed but replaced by enhancing the record concept to allow for what objects were. Happily

Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types

On 11/18/2013 10:51 PM, Sieghard wrote: Hallo Michael, Could you please keep sufficient context so even a casual reader can surmise what was meant? Thank you. Nope. That is what message threads do. So you say a single bit can be signed? Yep. The highest order bit in a number in the 2's

Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types

On 11/18/2013 11:03 PM, Sieghard wrote: Even if it is larger than any of the other operands? Yep. That is how it usually is done. Extend or sign-extend after the operation if the target is larger, truncate if it is smaller. Size extend always at runtime? Yep (If necessary): Adding leading

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/18/2013 05:26 PM, Martin Schreiber wrote: On Monday 18 November 2013 17:16:03 Ivanko B wrote: Also CASE doesn't accept enumerated type. FPC and MSElang do accept enumerated types. C as well. :-) -Michael --

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/18/2013 08:42 PM, Sieghard wrote: Which defeats the intention of case as a _calculated_ selector statement. How the jump is done is up to the compiler optimization not of the syntax. For only a few cases it might use just do multiple compares, For a sequence of numbers with not too many

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/18/2013 09:23 PM, Sieghard wrote: Though I doubt that there might be any sufficienty urgent need, can't you _always_ use any external program for preprocessing any of your source files, even be it manually before you compile it? You could even use a program compiled with the compiler

Re: [MSEide-MSEgui-talk] MSElang, compound statements

On 11/18/2013 10:53 PM, Sieghard wrote: Now, how can you pass an object that's meant to be kept unaffected by anything happening in the procedure or function? Well, yes, you simply can't. Of course you are right. Maybe inventing constant objects might be a nice extension to Object pascal.

  1   2   >