[MSEide-MSEgui-talk] Betriebsausflug

[Michael Schnell]

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<mailto:mschn...@lumino.de>
www.lumino.de<http://www.lumino.de>

[cid:image002.jpg@01D9A51A.FD7F4750]<https://www.facebook.com/luminogmbh/>
[cid:image003.jpg@01D9A51A.FD7F4750]<https://www.instagram.com/lumino.krefeld/>


Geschäftsführung:
Dipl.-Ing. Rolf Aengenendt
Dipl.-Betriebswirt Mario Fullert

Handelsregister HRB 1682 Amtsgericht Krefeld


Der Inhalt dieser Mitteilung kann vertraulich und/oder gesetzlich bzw. 
rechtlich geschützt sein. Falls Sie nicht der von der LUMINO Licht Elektronik 
GmbH beabsichtigte Empfänger der Mitteilung sind, dürfen Sie die Mitteilung 
nicht gebrauchen, kopieren, weiterleiten oder verbreiten. Wenn Sie nicht der 
richtige Adressat sind oder diese Mail irrtümlich erhalten haben bitten wir Sie 
freundlich, uns an i...@lumino.de<mailto:i...@lumino.de> eine entsprechende 
Nachricht zu senden, sowie die erhaltene Mitteilung sofort zu vernichten bzw. 
vollständig aus Ihrem System zu löschen. Das unerlaubte Kopieren sowie die 
unbefugte Weitergabe dieser Mail sind ebenfalls nicht gestattet. Im Übrigen 
lehnt die Lumino GmbH jede Haftung für Irrtümer oder Auslassungen im 
Zusammenhang mit der Mitteilung ab, welche wegen der Verwendung des Internets 
entstehen.

Informationen über Ihre gespeicherten Daten finden Sie auf unserer Homepage 
unter Datenschutz<https://www.lumino.de/erklaerung-zum-datenschutz.html>.
___
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

[Michael Schnell]

> 
> 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 code page, or "TMyString = String(CP_UTF16) with 
CP_UTF16 being defined = 1200; meaning  utf-16. Hence a String (type) can be 
defined to hole either of several different encoding variants, with an element 
size of either of 1, 2 or 4 bytes. If assigning a string content to some string 
variable, an automatic cote conversion will be done. Martin did think this is 
abysmal. And he is right, as this breaks compatibility in many cases and asks 
for a lot of nasty misconceptions.

Some messages above I wrote: 
I had been discussing this with Martin some two years ago. We agreed that the 
way it's implemented in Delphi (and even more inconsistent) in fpc is not at 
all optimal, and he said he would not do new strings in mselang. I did not hear 
any news about this since that time. In fact I wrote an article about a (IMHO) 
more consistent way to implement code aware strings -> 
http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support

-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

[Michael Schnell]

> 
> 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 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

[Michael Schnell]

Ø  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


___
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

[Michael Schnell]

> 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

[Michael Schnell]

> > 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 is to hold characters in the 
default ANSI code of the OS, rather than simply using " MyUTF_String: String;" 
(which is short for " MyUTF_String: String(CP_DEFAULT);" ) and would mean 
UTF-16 encoding with Delphi and UTF-8 encoding with fpc. 

If you now do "MyUTF_String := MyANSI_String;", Delphi or fpc would 
automatically convert the character encoding appropriately. 

But what about mselang on that behalf ? 

Maybe MSEIDE is done in a way that it compiles with fpc  (i.e. UTF-8 strings, 
unless explicitly denoted otherwise), and allows the meslang String paradigm 
(whatever it might be), nonetheless. 

-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

[Michael Schnell]

> -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 what you ask.
> 
> If you take a look at /mselang/test/base/string/  you will see (and test if 
> you
> want) that strings are perfectly implemented.
> 
> https://github.com/fredvs/mselang/tree/master/src/test/base/string
> 
> Fre;D
> 
> 
> 
> 
> 
> 
> 
> --
> Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
> 
> 
> ___
> mseide-msegui-talk mailing list
> mseide-msegui-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk




___
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

[Michael Schnell]

> 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 it's implemented in Delphi (and even more inconsistent) in fpc is not at 
all optimal, and he said he would not do new strings in mselang. I did not hear 
any news about this since that time. In fact I wrote an article about a (IMHO) 
more consistent way to implement code aware strings -> 
http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support

-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

[Michael Schnell]

> 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 



___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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.


But it needs to be monitored or configured whenever necessary.

Here either
 a) some hardware could be provided to have the maintainer do that 
(i.e. a local GUI using some standard library (such as mseGUI) and some 
standard widget set)
 b) a standard web server or web server interface (such as CGI or 
Apache API) is implemented and a standard  browser is used to attach to 
the device.
 c) some propriety protocol and a dedicated software to run on a PC is 
implemented. The communication could be either defined by the GUI 
library (-> ifi) or be propriety according to the needs of the 
application (GUI and "Business-Code" separation).


Finally:
 b1) part of the application runs on the remote site in the browser, 
the communication could be either defined by the GUI library (-> ifi) or 
be propriety according to the needs of the application.



The application might either run on dedicated hardware or on a web server.

Now in a perfect world it should be possible do to a normal (mse-)GUI 
application (->a) and just set a switch to compile it to work according 
to (->b).


Of course it would be acceptable if only a subset of the full range of 
visual components is provided in such portable way.


Obviously b) and b1) ask for pas2js (or even better for pascal to 
webassembly) compilation.


-Michael

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 18.12.2017 16:24, Martin Schreiber wrote:


Sure. Please have a look to the MSEgui sources, they are here:
https://gitlab.com/mseide-msegui/mseide-msegui/tree/master/lib/common

Do you really think that code is appropriate to run as Javascript?

Of course this will be a decent challenge :-).

And existing code itself is not the only challenge. On top of that the 
code would need to be enhanced to use the basic widgets (or whatever 
such is called) provided by the browser, instead of the basic widgets it 
currently use (and which supposedly are different depending on the 
OS/Widgetset it is compiled for).


The original mail by Michael Van Canneyt suggests that something like 
that would be planned with Lazarus.


I'm staying tuned

-Michael


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 writing any 
additional code.


-Michael


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 transpiler. It compiles Object
pascal, and emits Javascript. The javascript is usable in the browser, 
and

in Node.js. 


Maybe with that compiling the ifi "GUI" component to run in a Browser 
(and have it attach to GUI-less fpc applications) is in reach...


For me this would be a major reason to use and recommend mseGUI.

(IMHO fpc for Webassembly would be even more viable, but AFAI this is 
just in a very early stage right now...)


-Michael


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

[MSEide-MSEgui-talk] Rich internet Application

[Michael Schnell]

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) ???


IMHO using mse it should be possible to be enhanced with an easy to use 
framework for "rich Internet applications" by this. Making use of 
goodies provided by mse (but not by Lazarus):


 - mse-IFI for doing a fully grown server based application with a 
remote GUI

 - the IFI GUI part compiled by pasjs running in the Browser
 - WebSockets for communication between them

The not that much "Windows inspired" GUI in mse-gui might be better 
suited to allow the GUI designer to create the resources for a 
browser-based GUI.


-Michael

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 "applications" 
(with an event queue infrastructure to allow for event driven 
programming including using TTimer and TThread.Queue / 
TThread.Synchronize without manually calling checksynchronize) with no 
GUI binding, hence a "console application" or daemon.


-Michael
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 event (I in Delphi and Lazarus use 
TThread.Queue for such) and the main thread should react in the event 
handler. E.g. do  a property "On" in your outer class, if is not 
handled completely in the outer class itself, but the user of same is to 
define the code to be run in the action).


-Michael
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 a 
GUI application features a queue that can handle events, while non-LCL 
enabled (or "non-GUI") programs can use TThread, but not TApplication. 
Nonetheless, there, you still can use TThread.Queue (and 
TThread.Synchronize) if you implement the fetch from the queue yourself 
by "checksynchronize()", as the queue for TThread.Queue and 
TThread.Synchronize itself is implemented in the fpc RTL and does not 
need the LCL.


This said, IMHO, providing TMSEthread.Queue does seem appropriate.

-Michael

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] WebAssembly

[Michael Schnell]

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 project that should run 
on a non-monitored server (i. e. as a part of a kind of "embedded" 
application). Besides decent PC applications (e.g. behind a standard Web 
server at a provider's site), there also might be rather small self 
contained "gadgets" providing a web server. The new name of such devices 
is "IOT" and a real hype at the moment. Enabling mse user to easily do 
software for those IMHO is a very viable issue.

Now such programs or devices do need maintenance, and here they could 
provide a website showing their GUI in the users' Browser.

With the method described these projects could be developed and tested 
locally (in a user friendly "RAD" type of developing process) and be 
"split up" using ifi to run freely on the server unless somebody decides 
to attach.

-Michael

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

[MSEide-MSEgui-talk] WebAssembly

[Michael Schnell]

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 became the first browser to support
WebAssembly
") 


[1] .


Karoly Balogh (Charlie/SGR) is working on this, and as far as I know has 
already some degree of

success. There is a bounty for initial webassembly support..

Michael.

With WebAssembly I think you could do "very rich Internet applications" 
(I understand this means a server based applications with a remote GUI 
running in a Browser) purely using Pascal. No Java script any more !


As mse already features "ifi" that can do remote-GUI applications, it 
might be possible to run the ifi GUI part in a browser, allowing to 
attach to any server based ifi application. This would be exceptionally 
cool :)


(Of course I don't know how Widgets are done and used with WebAssembly...)

-Michael
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 
FreeBSD.

Why then does this distribution  allow for Linux and Windows executables 
(needing much more different APIs) but not for Mac OS executables ?

-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] [fpc-pascal] polYdev release 1.0 with fpc as superstar.

[Michael Schnell]

> 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

--
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

The cause why I posted this here is that mseGUI is pre-installed.
-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] [fpc-pascal] polYdev release 1.0 with fpc as superstar.

[Michael Schnell]

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 Windows 32 bit.
>
> No virtual machines needed, the compilations are fast and use the native
> compiler of each system.
>
> polYdev is shipped/configured with fpc 3.0.0 for FreeBSD 64/32, Linux 64/32,
> and Windows 32 bit.
>
> Here how to install polYdev:
>
> - Download the release from here:
>https://mega.nz/#!fwwRkLrQ
>
>This is the key Mega will ask:
>!0Pw4NOrCbiCffB3cZ7IrhY52cmaAp3Oa-jU99y5hNPY
>
> - Load and run the iso.
>
> - If you use a virtual machine, 2 gigas of ram are needed.
>
> - When the system is installed on device, install programs via menu "Install
> programs".
>This will install fpc and all the needed libraries for poly-compiling.
>
> - In /usr/local/share/ideu/prj_test_multisys/, there are demos of fpGUI and
> MSEgui poly-system.
>
>You may test it with ideU, all is pre-configured.
>   
>The source of all fpc fpGUI and MSEgui applications in the disto are in
> /dist/src.
>
> - Enjoy.
>
> Here fpc poly-sys in action:
>
> 
>
> Fre;D
>
>
>
>
>
> -
> Many thanks ;-)
> --
> View this message in context: 
> http://free-pascal-general.1045716.n5.nabble.com/polYdev-release-1-0-with-fpc-as-superstar-tp5726374.html
> Sent from the Free Pascal - General mailing list archive at Nabble.com.
> ___
> fpc-pascal maillist  -  fpc-pas...@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


--
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 available on the Target under Win 
IOT might depend on the hardware. I don't assume IOT can prevent 
mouse/touch and keyboard handling.

So this is a very moving target.

OTOH as IOT seems to be meant mainly as an OS for headless applications, 
a remote GUI would be more appropriate. ( see -> 
http://ms-iot.github.io/content/en-US/Faqs.htm )

Here your old "ifi" project could be a nice idea.

-Michael

--
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

[MSEide-MSEgui-talk] Win 10 IOT Core

[Michael Schnell]

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 Intel Arch, fpc/Lazarus "Windows" programs will 
simply run in Win 10 IOT Core (and a colleague of mine already tested 
that his Delphi programs do run on Win 10 IOT Core on a MinowBoard Max.)

What about Win 10 IOT Core for ARM ? I suppose that some work needs to 
be done to support Win 10 IOT Core on ARM.


We found that Win IOT  sirs not support the GDI winapi. Nonetheless 
Delphi "Service Applications" do run normally, while normal Delphi 
applications can't show a Form.

But Win IOT does support DirectX so a GUI would be possible, if the 
"Widgets" are provided by the application itself.

Is something like that possible with mseGUI ?



-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] Produced code of MSElang and FPC

[Michael Schnell]

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

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 03/23/2015 06:36 PM, Martin Schreiber wrote:

> Currently I am implementing "class" for the llvm-bitcode backend.
AFAIK, LLVM is done with C++ in mind.

I do know that Delphi classes are rather incompatible with C++ classes 
and so when using a C++ DLL/.so with fpc or vice versa you can't pass 
instances of classes.

Will this be mended in mselang ?

-Michael

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 01/31/2015 12:35 PM, misu kun wrote:
> fpc disappoint me , look at this test
>
AFAIK, there once was a project to have the fpc (as a "frontend") 
produce code for the LLVM backend , This seems rather doable, as fpc can 
produce code for a lot of "archs" not only including X86, x86-64, ARM 
32, ARM 64 (?), 68K, PPC, MIPS, but also Java Byte Code and Java Script 
source code (?) ) Now, LLVM needs just another "virtual object code" 
supposedly similar to Java Byte Code. Hence LLVM could be just a new 
arch for fpc.

-Michael

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 lot of sense to (additionally to the current 
Windows versions) offer Linux versions to the customers. So I suggested 
to do that via fpc.

> I had not thought in this particular case but I don't
> think that is a good way to go.

The only "good way" would be a (future) Lazarus / fpc version that is 
greatly a workalike with the (then) current Delhi version - including 
the (decently flawed) String implementation Delphi provides).

-Michael

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 be able to do modifications to their work-in 
progress, and always be able to compile to programs usable by our customers.

-Michael

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 any current Delphi version.  And they would like to be 
able to provide a Linux (PC and ARM) version of their stuff.

-Michael

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 11/28/2014 04:04 PM, Martin Schreiber wrote:
> MSElang has "string8" (utf-8), "string16" (utf-16), "string32" (UCS-4)
> and "bytestring" which can hold any 8-bit encoding or binary data.
>
With that you also need TStrings8, TStrings16,and TStrings32, and all 
its siblings need 8, 16 and 32 interfaces.

I am not sure if this is really workable.

Moreover there is no support for multiple ANSI code pages. While I think 
I would not miss that one, I am sure others will.

-Michael

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 implementation done for that yet. As Graeme suggested in the 
discussion in fpc-devel, the Embarcadero syntax designers provided a 
really nice paradigm (even though I hate the misleading "ANSI" and 
"CodePage" wording, which easily could be avoided), but the Embarcadero 
code implementers messed it up. And fpc simply followed :-( .

-Michael

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 objfpc;
> 2- Forget old codes. Will break compatibilities, yes, but we will have
> a better compiler;
> 3- RTL, LCL, whatever... needs to talking using the same encode;
>
In fact they do something like this by allowing the user to select 
sevberal modes (e.g. "fpc" "delphi" and  "delphiunicode") I.e. there are 
several different implementations (and syntax) for several issues.

But doing a decently better implementation of Unicode support is a lot 
of work and nobody pays them :-( .

-Michael

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 
one-byte-per-character String type that uses an (ANSI-compatible) 
encoding restricted to a certain set of languages (usually defined by 
the system locale) is not versatile enough."

In fact we (company) do Software targeted to multiple countries (in 
Delphi) to do that, its very difficult without Unicode support.

OTOH, decently handling Unicode is not an easy task. Delphi 
(unsuccessfully) tries to hide the ubiquitous Unicode pitfalls from the 
("rapid") application developer.

ftp is on the tracks of Delphi, and might (or might not) do a better job.

-Michael

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 your 
software with them.

-Michael


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 10/02/2014 12:10 PM, Martin Schreiber wrote:
> On Thursday 02 October 2014 11:04:08 Michael Schnell wrote:
>> (Does mse support Event Queues for worker threads ? )
>>
> Yes, teventthread supports it.
So I did remember correctly :-) :-) :-)

-Michael

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 working in parallel with the Event Queue provided by TThread).

My attempts to discuss this in fpc-develop seem to be considered opening 
a can of worms :-( . (In fact - IMHO - also existing Lazarus Widget 
Types could benefit from directly using the Event Queue in the RTL 
instead of doing their own parallel queues.)

Nonetheless since the (not yet released) TThread implementation in the 
svn finally provides the Delphi compatible (since Delphi 7 or so) 
TThread.Queue procedure, I was able to do a draft for the "Interface" 
unit providing the TApplication and TTimer objects for an "active 
non-GUI" (nearly) fully LCL-compatible "widget type". In fact, this is a 
rather lightweight and easy thingy. It does not contain any arch or OS 
depending code.

Finally. A more versatile TThread implementation could provide an 
(optional) Event Queue instance (plus the appropriate "main Loop) for 
each thread, allowing event driven programming for worker threads. 
(Right now the Event Queue is strictly a single "Class" thingy doing the 
Event Queue only for the Main Thread. )

IMHO, Event Queue enabled worker threads might be a nice base for 
providing "parallel loop" or similar language/library constructs to 
support easy-to-use speeding up certain applications in SMP.

(Does mse support Event Queues for worker threads ? )

(I did this only for fun and for research. I don't really need it any 
more, as my colleagues seemingly will never find the time to port their 
(huge) embedded Delphi projects to Linux using fpc.)

-Michael

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] General

[Michael Schnell]

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 write a personal mail to Martin containing an offer what you 
intent to pay for this several man-year worth of work :-) .

Everybody will be happy top take advantage of the results and praise you 
for making this happen.

-Michael

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 is this true ?

Of course any language-introduced operation needs to be thread-save ! If 
library functions are not thread-save this needs decent documentation.

Composed Types (records, Objects, problem: complex and int64 on a 32 Bit 
CU) need to be documented as not being allowed to be considered a being 
handled in an atomic way, but it should be save to use Strings (as any 
not obviously composed language objects) in any thread without restriction.

OTOH, e.g saying "TList" is not thread save is not clear enough, It 
should be stated that using multiple instances of TList in multiple 
threads is save as long as the same instance is not used in multiple 
threads. OTOH TThreadList is supposed to be thread save even in this use.

-Michael

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 open arrays with differently typed 
variables for this, including the possibility to define constants of 
this type on the fly in function calls. This is at least equivalent.

-Michael

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 it works as if creating a 
variable of the appropriate type and assigning that value to it.

-Michael

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 same is true for typecasts.

C is more straight forward: typecasts don't look like a function so you 
are not astonished to see that they don't perform any action.

abs() does not exist in C (you can of course do a simple #define macro 
for that).

-Michael

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 what would be the result of this code ?


var i : card32;

i  := 4294967295;
i  := abs(i);

IMHO i needs to be 1.

  - 4294967295 = $
  - $ in signed is -1
  - abs of -1 is 1

-Michael

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 works differently 
for different argument types ?

What is the type of the result ?

-Michael

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 maxunsigned + value + 1, as 
any language I know just preserves the bits in the word.

-Michael


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 12/14/2013 06:24 PM, Ivanko B wrote:
> Maybe no UNSAFE (unsigned -2-signed etc
Only a few conversions are save; just extending the bit size.

  - Signed to unsigned looses the sign
  - Unsigned to signed of the same bit size looses one bit
  - integer to float looses bits (if the integer type is large enough)
  - float to integer looses fractions
  - enum to integer and vice versa is problematic.
  - ,,,

Michael

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

+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 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 (but not a "nice" solution).

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 11/24/2013 05:41 PM, Ivanko B wrote:
> Also how about BREAK() & NEXT() ? 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.

This a "nesting label" could be more appropriate. But this is rather 
close to a goto...

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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



--
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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

.. 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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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. Instead of introducing "result" as a 
ghostly variable (i.e as a syntax keyword) just omitting it looks rather 
logical.

But the concept could be easily extended to allow for

:= rvalue;

  in any location within a sub

and even allowing for

rvalue :=;

  in any location within a sub, as well

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 are "functions" that are allowed as lvalue. ( in
effect making function "results" a  "in" variables.

(A nice idea as well :-) :-) :-) )

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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" ore 
similar), there were functions with multiple return values and the 
syntax was just

var1,var2 := MultResFunc(arg1,arg2);

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 
effect making function results "var" variables.

(Funnily this is done "by chance" in Delphi 2006 with dynamic arrays as 
function results.

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 11/22/2013 06:55 PM, Martin Schreiber wrote:
>
>   {$rtti on}
> property prop1: int32 read fprop1 write fprop1; //streamed
>   {$rtti off}
To me this looks worse than just "published" (it does not make much 
sense to allow for  rtti aware private properties.

But anyway, does the compiler need to know ? Could the properties not 
always be rtti aware and the RTL startup code search for those to be 
initialized from a resource ?

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 11/22/2013 09:26 AM, Martin Schreiber wrote:
>
> Use 'method' instead of 'sub' everywhere or introduce a new keyword?
>
Everywhere.

I decently dislike "sub". For me, a keyword should be "speaking" (like 
"to" or "for") and not be an abbreviation. "method" is a lot shorter 
than "subroutine" and more speaking than "sub".

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 to be.
>
>> (With fpc you need to add @ for the second, which I think is extremely
>> ugly.)
> But it is thoroughly consistent with the use of "@" with variables, where
> it returns their address as well.
> This makes the C approach (above) look inconsistent.
Is this really  you speaking ?

Dealing with explicit pointers is a typical way of C programming. It's a 
beauty of Pascal that this usually is not necessary (i.e. hidden behind 
other concepts such as object instance and "with").

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 is well know with language independent 
theories of object-programming.

I would not mind extending it to stuff outside of objects (inherently 
called classes :-) )

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 optimization ?

I do trust him (seemingly more than he does himself, see non-constant 
"case labels")

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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". It is commonly understood in the 
"Object"-world, and it's less likely that a program to be ported uses 
same as a variable name.

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

Sounds rather new bit really nice !

Moving form Delphi to mseLang seems similar as when moving from C to 
Java :-) . (only better :-) :-) )

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

and

cpp --help

outputs
...
   -Xassembler Pass  on to the assembler
   -Xpreprocessor  Pass  on to the preprocessor
   -XlinkerPass  on to the linker
...

???
-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 (arch-depending) C compiler (supposedly 
"cpp" = "C plus plus" ), and not the (arch-independent) preprocessor.

Thus I still suggest that the preprocessor is build in the "main 
executable" file called gcc ("gcc" = Gnu Compiler Collection").

Thus the preprocessor should be usable with all languages supported by gcc.

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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

--
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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

I see. But the definition I have in mind does not provide for taking 
multiple alternatives.

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 in fact is a function call, it could have side-effects that affect 
the selection of the other candidates.

But this is true for many other syntax elements, as well.

E.g. boolean operands are not evaluated if not necessary:


function b: Boolean;
function c: Boolean

var a : Boolean

  a := b and c;

Here, c might have a side effect but is not (necessarily) evaluated if 
the result of b is false. (At least this is how I understand most syntax 
definitions are done: evaluation from left to right.)

This this user code is erroneous if c has side effects.

Moreover in case of site effects the statements

   a := b and c.
and
a := c and b.

are not equivalent. (Obviously again: This this user code is erroneous 
if b or c have side effects. )



Same of course holed for case: it is to be evaluated from left to right 
(i.e. from top to bottom).

For me, the "case a of" syntax should be just an abbreviation of an 
"else if" cascade of

if a=x1 then begin
  ...
  end else if a = x2 then begin
  ...
  end else if a = x2 then begin
  ...
  else begin
end;

In what low level operations this results is up to the compiler 
optimizations. (Martin: Happy coding ! :-) )

If there are side-effects within the evaluation of the decision-terms, 
is is obviously possible that some re not evaluated. The compiler needs 
to be able to rely on this fact and thus any user code that violates 
this rule needs to be considered as erroneous (see the boolean example 
above).

Of course the order of the blocks might change the behavior. Either the 
compiler needs to take this into account, or it needs to be defined that 
any user code that relies on the order needs to be considered (and 
documented) as erroneous (see the boolean example above)

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 certain compiler switches are set).

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.

(With fpc you need to add @ for the second, which I think is extremely 
ugly.)

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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
 Result := 'Not The string result';
   Result := '>>>' + Result + '<<<'
  end;

Here you don't need to define a variable for the intermediate value.

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 
operation between them and a "bigger" partner) the obvious way is 
sign-extension (i.e. duplicate highest order bit i.e. "sign" bit) for 
signed types  and zero-extend unsigned types. As the extend operation is 
not allowed to change the value, it's obvious that for a 1 bit signed 
type the possible values are 0 and -1.

This is what I tried to show with the example.

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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. Regarding the _language_ it's 
nothing but an not necessary restriction to disallow them.

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

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 Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 11/21/2013 12:38 AM, Sieghard wrote:
> You might have called it with the wrong syntax...

RecheckingI suppose the problem was that I mostly use 
cross-compiling, and here the name is not "cpp" but something like 
"xcpp" (which is funny as the proprocessor is arch-independent by 
design).

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

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

[Michael Schnell]

On 11/21/2013 12:38 AM, Sieghard wrote:
> these syntactic elements are _removed_ by the preprocessor. ...
Thus the compiler will not see them. If it's a necessary element of the 
compiler's syntax, a coprocessor that always removes it can't be used.

-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 game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk