Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2013-04

Synchronize(dummyproc) with Linux.

51 messages · 9 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Fred van Stappen

This about audio and fpc and fpGUI and LCL and Linux. (working good with Windows)
Have some trouble with threads synchronize() procedure. The main thread.execute is a loop to read-write audio data. Inside the loop i use synchronize(myProc) to synchronize some graphic component ( like taskbar.position, position.text,...). With LCL the graphic synchro is good and the quality of sound is ok and not altered with synchronize(myProc). With fpGui the synchro is good but not the quality of sound.
Some audio chunk are omitted when using synchronize(myProc).

I was thinking that the reason was the Graphic-refresh but it is not. If i do a synchronize(dummyproc) i have the same bad result. Without synchronize(dummyproc), the sound is perfect. Here some code :

>The main thread.execute
procedure TUOS_Player.Execute;
begin
...
repeat
...
if LoopProc  nil then synchronize(LoopProc);
...
end;
end;
> And here LoopProc := DummyProc :
Procedure TSimpleplayer.DummyProc ;
begin
  // Nothing !
  end;

I have a test example for Linux 64 bit.

There are 3 binaries from same code : fpGUI, GTK2, Qt.

On the fpGUI demo, there are 3 checkboxs more,
- With syhchro Grahic
- With synchro Dummy
- Without syhchro

On my slow computer, the sound is altered while using synchro, even if the proc is dummy ! Why, what do synchronize() if the procedure is dummy ? Here the demo test :

_*https://sites.google.com/site/fiensprototyping/fpGUI_UOStest.tar.gz*_

Download the zip file, and run the binaries in root folder (everything is included and ready to use). The source are insrc.

Many thanks

Reply by email

silvioprog
to Fred van Stappen: This about audio and fpc and fpGUI and LCL and Linux. (working good with Windows) Have…

2013/4/30 Fred van Stappen

Show quoted text 52 lines
This about audio and fpc and fpGUI and LCL and Linux. (working good with Windows) Have some trouble with threads synchronize() procedure. The main thread.execute is a loop to read-write audio data. Inside the loop i use synchronize(myProc) to synchronize some graphic component ( like taskbar.position, position.text,...). With LCL the graphic synchro is good and the quality of sound is ok and not altered with synchronize(myProc). With fpGui the synchro is good but not the quality of sound. Some audio chunk are omitted when using synchronize(myProc). I was thinking that the reason was the Graphic-refresh but it is not. If i do a synchronize(dummyproc) i have the same bad result. Without synchronize(dummyproc), the sound is perfect. Here some code : >>The main thread.execute procedure TUOS_Player.Execute; begin ... repeat ... if LoopProc nil then synchronize(LoopProc); ... end; end; >> And here LoopProc := DummyProc : Procedure TSimpleplayer.DummyProc ; begin // Nothing ! end; I have a test example for Linux 64 bit. There are 3 binaries from same code : fpGUI, GTK2, Qt. On the fpGUI demo, there are 3 checkboxs more, - With syhchro Grahic - With synchro Dummy - Without syhchro On my slow computer, the sound is altered while using synchro, even if the proc is dummy ! Why, what do synchronize() if the procedure is dummy ? Here the demo test :*https://sites.google.com/site/fiensprototyping/fpGUI_UOStest.tar.gz* Download the zip file, and run the binaries in root folder (everything is included and ready to use). The source are in src. Many thanks Try Queue instead Syncronize.
Silvio Clécio My public projects - github.com/silvioprog

Reply by email

Fred van Stappen
to silvioprog

Try Queue instead Syncronize. --
Silvio Clécio
My public projects - github.com/silvioprog

Thanks Silvio, i gonna try. But i want to understand why it does not works good with Syhchronize. I was thinking that, maybe, LCL does not use the same level of priority while creating thread than original fp. Is that wright ? And why Synchronize a dummy proc have affect on parent thread. Other question :
Does it exist a level of priority for Synchronize, like threads have ? Thanks

Reply by email

Sven Barth
to Fred van Stappen: This about audio and fpc and fpGUI and LCL and Linux. (working good with Windows) Have…
Fred van Stappen wrote 16 lines
This about audio and fpc and fpGUI and LCL and Linux. (working good with Windows) Have some trouble with threads synchronize() procedure. The main thread.execute is a loop to read-write audio data. Inside the loop i use synchronize(myProc) to synchronize some graphic component ( like taskbar.position, position.text,...). With LCL the graphic synchro is good and the quality of sound is ok and not altered with synchronize(myProc). With fpGui the synchro is good but not the quality of sound. Some audio chunk are omitted when using synchronize(myProc). I was thinking that the reason was the Graphic-refresh but it is not. If i do a synchronize(dummyproc) i have the same bad result. Without synchronize(dummyproc), the sound is perfect. Here some code :

With Synchronize you need to keep in mind that the execution of the calling thread will be blocked until the given method was executed in the context of the main thread. So if the main thread doesn't call CheckSynchronize often enough your thread will hang longer (Note: CheckSynchronize is internally called by the event loop of the widgetset). Like Silvio said if you use FPC 2.7.1 you should use the new Queue method instead of Synchronize, because this won't block the calling thread. Alternatively you could try to use Application.QueueAsyncCall (only available for LCL applications).

Show quoted text 12 lines
I have a test example for Linux 64 bit. There are 3 binaries from same code : fpGUI, GTK2, Qt. On the fpGUI demo, there are 3 checkboxs more, - With syhchro Grahic - With synchro Dummy - Without syhchro On my slow computer, the sound is altered while using synchro, even if the proc is dummy ! Why, what do synchronize() if the procedure is dummy ?

Do you use fpGUI directly or fpGUI through the LCL? In both cases it could be the case that the event loop is doing a CheckSynchronize to seldomly. Maybe you should better ask this on the lazarus mailing list, so that the Lazarus devs could adjust this if it is a problem in the fpGUI glue code for the LCL.

Regards,
Sven

Reply by email

Fred van Stappen
to Graeme Geldenhuys: And on my 64-bit Linux (Ubuntu 10.04) VM the sound and graphic updates - Graeme -
And on my 64-bit Linux (Ubuntu 10.04) VM the sound and graphic updates.

That are good news ;)
But does not respond to the question :
Why synchronize a dummy-empty proc affect the parent thread ( and in this case the main thread is a audio process) ? Sure that with good cpu you do not feel it. But with a atom cpu, very close than arm cpu, i can test the result live. And trust me, something append while synchronize a dummy proc. And i really want to understand why.

Reply by email

Graeme Geldenhuys
to Fred van Stappen: That are good news ;) But does not respond to the question : Why synchronize a…
Fred van Stappen wrote
you do not feel it. But with a atom cpu, very close than arm cpu, i can test the result live. And trust me, something append while synchronize a dummy proc. And i really want to understand why.

Like I said before, I have no idea why that is the case on your system. If I can find a similar reproducing example, I'll test it on my Raspberry Pi - that is the slowest system (by a big margin) I have available.

Regards,
- Graeme -

Reply by email

Fred van Stappen
to Graeme Geldenhuys
that is the slowest system (by a big margin) I have available.

Im very interested by the result.
But i continue to think there is something strange with synchronize(). In my logic, synchronize(dummyproc) must have NO effect on the parent thread. And it have.
I can imagine (and accept) that synchronize(Graphicproc) have effect on parent thread but synchronize(dummyproc), that i can not understand (and accept). PS : Im busy to upgrade from 2.6.2 to 2.7.1 (what a hell to do a upgrade !) and gonna try queue(dummyproc) instead and say the result. Thanks

Reply by email

Sven Barth
to Fred van Stappen
Fred van Stappen wrote 8 lines
> that is the slowest system (by a big margin) I have > available. Im very interested by the result. But i continue to think there is something strange with synchronize(). In my logic, synchronize(dummyproc) must have NO effect on the parent thread. And it have.

It seems that you didn't read what I wrote. Synchronize always blocks until the given method was executed by the main thread. So even if your method is empty there will be a delay until the mainthread processes the synchronized method. And the more busy the main thread is (e.g. updating the GUI) the more time it takes until it can process a synchronized message. Also multiple Synchronize events will be executed in multiple runs of CheckSynchronize runs, because the "queue" in pre-2.7.1 can only hold one element. In 2.7.1 the queue can hold multiple methods enqueue by Synchronize and Queue.

Regards,
Sven

Reply by email

Fred van Stappen
to Sven Barth

@ sven : Many thanks for answer ( and of course i had read and study deeply your clear earlier topic ).

So

even if your method is empty there will be a delay until the mainthread processes the synchronized method.

Ok, difficult to understand that a empty method gives a delay, but if it is a axiom, nothing to understand, i have to accept it . Many thanks.

Hope gonna have better result with queue() in fpc 2.7.1. (But what a nightwear to do a upgrade of fpc, i tremble to the idea of having to do it and the loooooots of time it gonna takes me.

But when you love, you do not count. ;)
Many thanks

Reply by email

Michael Van Canneyt
to Fred van Stappen
Fred van Stappen wrote 5 lines
@ sven : Many thanks for answer ( and of course i had read and study deeply your clear earlier topic ). >So even if your method is empty there will be a delay until the mainthread processes the synchronized method. Ok, difficult to understand that a empty method gives a delay, but if it is a axiom, nothing to understand, i have to accept it . Many thanks.

This is not an axiom, but simply a consequence of the definition of Synchronize().

Synchronize submits a procedure for execution by the main thread, and waits till the main thread has processed it.

Nowhere does it state that this will be done immediatly. The code in the main thread is responsible for checking at regular intervals if a procedure was scheduled, and if so, execute it.

Michael.

Reply by email

Sven Barth
to Fred van Stappen
"Fred van Stappen" wrote
> Synchronize submits a procedure for execution by the main thread, and

waits till the main thread has processed it.

Ok, i understand that, but if that procedure is dummy, i do understand

why it takes a delay.

The Synchronize code can not know that the method you passed is an empty one, so it's handled like every other method. And even if the compiler could know that it is an empty one it could not judge what Synchronize is doing with it (especially since Synchronize and the execution code in CheckSynchronize is very loosely coupled). Also it is consistent that an empty method is handled the same as a non-empty one.

And again: the delay until Synchronize returns is not only dependant on the runtime of the method, but also on the frequency in which the main thread calls CheckSynchronize in which the method will finally be executed.

Regards,
Sven

Reply by email

Fred van Stappen
to Sven Barth
Show quoted text 5 lines
> Synchronize submits a procedure for execution by the main thread, and waits till the main thread has processed it. Ok, i understand that, but if that procedure is dummy, i do understand why it takes a delay.

The Synchronize code can not know that the method you passed is an empty one, so it's handled like every other method. And even if the compiler could know that it is an empty one it could not judge what Synchronize is doing with it (especially since Synchronize and the execution code in CheckSynchronize is very loosely coupled). Also it is consistent that an empty method is handled the same as a non-empty one.

And again: the delay until Synchronize returns is not only dependant on the runtime of the method, but also on the frequency in which the main thread calls CheckSynchronize in which the method will finally be executed.

Regards,

Sven
________________________________________________________________

Yep, Sven, that is a clear explanation.
Now, ok, i catch it.
Many thanks. ( and i gonna finally sleep good this night ). ;)

PS : Im a totally FPC-addicted and i like that ;).

Reply by email

Fred van Stappen
to Michael Van Canneyt: This is not an axiom, but simply a consequence of the definition of Synchronize().…
Show quoted text 7 lines
Hello. I want add access to AT-SPI interface. http://en.wikipedia.org/wiki/Assistive_Technology_Service_Provider_Interface Does it exist a pascal header for that ? Does anybody know how to do it, via fpc, not lcl ? Thanks.

Toc, toc, toc, is there anybody here ?
Nobody have some experience with AT-SPI and FPC ?
For example, Lazarus is working with ORCA but the application compiled with Lazarus does not work with ORCA. Could somebody help me to use AT_SPI with pure fpc (no LCL) ? Thanks.

PS : It is a shame that FPC does not care about assistive technology.

Many thanks.

Reply by email

Michael Van Canneyt
to Fred van Stappen
Fred van Stappen wrote 14 lines
>Hello. >I want add access to AT-SPI interface. > http://en.wikipedia.org/wiki/Assistive_Technology_Service_Provider_Interface >Does it exist a pascal header for that ? >Does anybody know how to do it, via fpc, not lcl ? >Thanks. Toc, toc, toc, is there anybody here ? Nobody have some experience with AT-SPI and FPC ? For example, Lazarus is working with ORCA but the application compiled with Lazarus does not work with ORCA. Could somebody help me to use AT_SPI with pure fpc (no LCL) ? Thanks. PS : It is a shame that FPC does not care about assistive technology.

Why do you say that ? As far as I can see, AT-SPI is a library like any other.

There are many libraries out there. We do not have the manpower to translate headers for all libraries. So it has nothing to do with 'caring'. It is a question of available manpower.

If it was not translated it means no-one had the need for it. To my knowledge, you are the first to ask about it.

Michael.

Reply by email

Sven Barth
to Fred van Stappen: Toc, toc, toc, is there anybody here ? Nobody have some experience with AT-SPI and FPC ?…
Fred van Stappen wrote 9 lines
>Hello. >I want add access to AT-SPI interface. > http://en.wikipedia.org/wiki/Assistive_Technology_Service_Provider_Interface <http://en.wikipedia.org/wiki/Assistive_Technology_Service_Provider_Interface> >Does it exist a pascal header for that ? >Does anybody know how to do it, via fpc, not lcl ? >Thanks. Toc, toc, toc, is there anybody here ?

It might help if you wouldn't start a new question by answering to a mail in an existing thread. I needed to search your first mail first, because it wasn't listed on the top level of the threads and you didn't directly answer to your previous message either...

Show quoted text 6 lines
Nobody have some experience with AT-SPI and FPC ? For example, Lazarus is working with ORCA but the application compiled with Lazarus does not work with ORCA. Could somebody help me to use AT_SPI with pure fpc (no LCL) ? Thanks. PS : It is a shame that FPC does not care about assistive technology.

It is not about not caring. You must not forget that FPC as well as Lazarus are developed in the free time of us developers. So it's more likely that things are implemented that are interesting to the devs. If you want to change something about missing support for assistive technology: patches are welcome (I know that this may sound harsh, but this is how it works). Or put up a bounty...

Regards,
Sven

Reply by email

Fred van Stappen
to Michael Schnell
> Except to tell the writer about his/her indecency :)

Yep, sorry but with my indecent "PS:...", already 5 answers !... So the question must be :

"PS : Why must i be indecent to have some answers..."

Thanks and sorry to disturb you.

Reply by email

Sven Barth
to Fred van Stappen
Fred van Stappen wrote 8 lines
> > Except to tell the writer about his/her indecency :) Yep, sorry but with my indecent "PS:...", already 5 answers !... So the question must be : "PS : Why must i be indecent to have some answers..." Thanks and sorry to disturb you.

The point is nevertheless that you answered to an existing thread with a completely new/unrelated question. Twice. It's not only unpolite to do this, but it's also less likely that someone sees your question as users which could answer you ignore the thread your question appeared in (and there are also people which out of principle ignore questions posted in that way).

Regards,
Sven

Reply by email

Fred van Stappen
to Sven Barth
The point is nevertheless that you answered to an existing thread

with a >completely new/unrelated question.

OK, my fault, i wanted to answer to my own tread an that answer appears like a new one ( i used ( RE: ... ) in place of (Re: ...). ).

Reply by email

Sven Barth
to Fred van Stappen
Fred van Stappen wrote 6 lines
>The point is nevertheless that you answered to an existing thread with a >completely new/unrelated question. OK, my fault, i wanted to answer to my own tread an that answer appears like a new one ( i used ( RE: ... ) in place of (Re: ...). ).

It's not about "RE" or "Re". I don't know what mail client you use, but in e.g. Thunderbird you have the possiblity to "Answer to Sender", "Answer to List" or "Answer to All". If you choose any of this options than Thunderbird will declare your message as an answer to that exact message. And if that message is now part of a different thread (in the current case the "Synchronize(dummyproc) with Linux" thread) then your message will appear as an answer to that. So you need either to select the correct message you want to answer to or at least don't use any of the "Answer to" menu items and use "Write" instead.

Regards,
Sven

Reply by email

Fred van Stappen
to Michael Van Canneyt: Why do you say that ? As far as I can see, AT-SPI is a library like any other. There are…
To my knowledge, you are the first to ask about it. Michael.

OK, guys, i apologize. It was not the wright way to do things moving. Now, if you can be cooler, i asked that because, like you, i was very surprised that some blind developers says me that they really want to use fpc but nothing was done for them. Thus i have seek for some doc about at-spi and finded quasi nothing. If my mail was shocking, it was because i was shoched myself that i did not care about those people while developing... And i want to contribute and translate the at-spi C header (if there are one). And if somebody have any knowledge about that, it will be welcome.

Reply by email

Michael Van Canneyt
to Fred van Stappen
Fred van Stappen wrote 10 lines
> To my knowledge, you are the first to ask about it. > > Michael. OK, guys, i apologize. It was not the wright way to do things moving. Now, if you can be cooler, i asked that because, like you, i was very surprised that some blind developers says me that they really want to use fpc but nothing was done for them. Thus i have seek for some doc about at-spi and finded quasi nothing. If my mail was shocking, it was because i was shoched myself that i did not care about those people while developing... And i want to contribute and translate the at-spi C header (if there are one). And if somebody have any knowledge about that, it will be welcome.

The usual way to do this is to use the h2pas tool.

I normally start with

Preprocess ugly macros

gcc -E /path/to/header/file > header_processed.c

and then

h2pas header_processed.c

(preferably with some options)

After that I add missing defines (constants and the like).

Michael.

Reply by email

Sven Barth
to Fred van Stappen: OK, guys, i apologize. It was not the wright way to do things moving. Now, if you can be…
Fred van Stappen wrote 11 lines
> To my knowledge, you are the first to ask about it. > > Michael. OK, guys, i apologize. It was not the wright way to do things moving. Now, if you can be cooler, i asked that because, like you, i was very surprised that some blind developers says me that they really want to use fpc but nothing was done for them. Thus i have seek for some doc about at-spi and finded quasi nothing. If my mail was shocking, it was because i was shoched myself that i did not care about those people while developing...

As already written: it was less shocking regarding the content, but the way you sent it :P

And i want to contribute and translate the at-spi C header (if there are one).

The C headers are documented here (I don't know where they are located though):
https://developer.gnome.org/at-spi-cspi/stable/
Also useable might be this:
http://accessibility.kde.org/developer/atk.php#coreclasses

And if somebody have any knowledge about that, it will be welcome.

As Michael wrote you should take a look at the h2pas tool that's distributed with FPC.

Regards,
Sven

Reply by email

Fred van Stappen
to Michael Van Canneyt: The usual way to do this is to use the h2pas tool. I normally start with Preprocess ugly…
Show quoted text 17 lines
The usual way to do this is to use the h2pas tool. I normally start with Preprocess ugly macros gcc -E /path/to/header/file > header_processed.c and then h2pas header_processed.c (preferably with some options) After that I add missing defines (constants and the like). Michael.

Many thanks Michael but translation of C header is my favourite game ;) Sure the translation is always hard.
What i want to ask is if somebody have knowledges about at-spi and if he can guide me how to begin, witch header use (there are lot of ), etc...

Tanks.

Reply by email

waldo kitty
to Fred van Stappen: with a >completely new/unrelated question. OK, my fault, i wanted to answer to my own…
Fred van Stappen wrote 5 lines
>The point is nevertheless that you answered to an existing thread with a >completely new/unrelated question. OK, my fault, i wanted to answer to my own tread an that answer appears like a new one ( i used ( RE: ... ) in place of (Re: ...). ).

that doesn't matter... it is the references field that matters... if there is one then the message belongs in an existing thread... without one, it is a new thread...

start new thread via "write new message" not "reply to existing thread" ;)

NOTE: No off-list assistance is given without prior approval. Please keep mailing list traffic on the list unless private contact is specifically requested and granted.

Reply by email

Sven Barth
to Fred van Stappen
Fred van Stappen wrote 6 lines
On 5/8/2013 04:34, Fred van Stappen wrote: >> PS : It is a shame that FPC does not care about assistive technology. No, it is a shame for me to have had doubts about fpc... FPC is assistive technology compatible. ( $(freepascal source)/packages/gtk2/src/atk/atk.pas ).

That is only ATK, not AT-SPI directly. Also a language can not be "not assistive technology compatible". It's just that you need the translated interfaces. Even if we wouldn't have translated ATK headers FPC would still be compatible, since someone would just need to translate it then...

Regards,
Sven

Reply by email

Fred van Stappen
to Sven Barth
That is only ATK, not AT-SPI directly.

Ok, what a jungle.
ATK is Accessibility Toolkit no ?
I was thinking that with atk, you can use at-spi library more easier. Also it seams that Qt use ATK for accessibility.
So, maybe, is it a good idea to use atk for pure fpc-console app (like fpGUI ) ? Or im totally wrong, i have to translate directly the c header of at-spi ?

Many thanks.

Reply by email

Sven Barth
to Fred van Stappen
Fred van Stappen wrote 10 lines
> That is only ATK, not AT-SPI directly. Ok, what a jungle. ATK is Accessibility Toolkit no ? I was thinking that with atk, you can use at-spi library more easier. Also it seams that Qt use ATK for accessibility. So, maybe, is it a good idea to use atk for pure fpc-console app (like fpGUI ) ? Or im totally wrong, i have to translate directly the c header of at-spi ?

The ATK library seems to have less dependencies than the AT-SPI library, but considering this I personally(!) would use neither of them for a console application or fpGUI, but better port AT-SPI completely over to Pascal... (but that's just me ;) )

Regards,
Sven

Reply by email

Fred van Stappen
to Sven Barth
>But better port AT-SPI completely over to Pascal...Aaarg, i promise to do it, so i have to do it...

( I was hoping that using a existing ATK pascal header and adapt it for console, but too many reference to GTK libs ( or Qt for the Qt atk-kit ).

So, lot of white nights in perspective... ;)

Thanks.

Reply by email

Sven Barth
to Fred van Stappen
Fred van Stappen wrote 5 lines
>> Or put up a bounty... Yes, i think it is the best solution ;) PS : Hum,... how much ?

I've never taken a bounty nor published one, so I can't tell. You'll need to judge how much a solution is worth for you and how much you think a developer will need so that he'll take the "challenge".

Regards,
Sven

Reply by email

Fred van Stappen
to Sven Barth
You'll need to judge how much a solution is worth for you and how much >you think a developer will need so that he'll take the "challenge".

The thing is that i discover AT-SPI one week ago. Somebody tell me that he (his factory) does not use fpc because there was no link for AT-SPI. So i have seek for infos about AT-SPi. First i have try some app compatible with orca. Impressive... ( Lazarus is working with orca but i do not have find how to do it work with my apps compiled with Lazarus, even with LCL ).

Also i have discover that assistive technology is very poor documented, maybe because the market is not big enough ( and not rich enough too ).

But the magic of Pascal is his clear human-like language. So, i think Pascal should be a perfect language for deficient people. ( i do not want to imagine how difficult it must be for those persons to develop in C, even if the C compiler is AT-SPI enabled.)

I promise (to myself) to do that change.
Of course i prefer to do it by myself, so i gonna much better understand that technology. Sadly, i do not know how to begin, what header translate,...

So, if money can change things, im happy too and i want to pay for it. But if you think it is not "the style of fpc" im totally ready to help for whatever ( or exchange the work for something that i know ). ;)

Reply by email

Paul Breneman
to Fred van Stappen
Fred van Stappen wrote 17 lines
> You'll need to judge how much a solution is worth for you and how much >you think a developer will need so that he'll take the "challenge". The thing is that i discover AT-SPI one week ago. Somebody tell me that he (his factory) does not use fpc because there was no link for AT-SPI. So i have seek for infos about AT-SPi. First i have try some app compatible with orca. Impressive... ( Lazarus is working with orca but i do not have find how to do it work with my apps compiled with Lazarus, even with LCL ). Also i have discover that assistive technology is very poor documented, maybe because the market is not big enough ( and not rich enough too ). But the magic of Pascal is his clear human-like language. So, i think Pascal should be a perfect language for deficient people. ( i do not want to imagine how difficult it must be for those persons to develop in C, even if the C compiler is AT-SPI enabled.) I promise (to myself) to do that change. Of course i prefer to do it by myself, so i gonna much better understand that technology. Sadly, i do not know how to begin, what header translate,... So, if money can change things, im happy too and i want to pay for it. But if you think it is not "the style of fpc" im totally ready to help for whatever ( or exchange the work for something that i know ). ;)

I'd like to see Free Pascal used more for "factory" (industrial) work and for the last 5.5 years I've tried to do that (along with encouraging embedded system development). This message thread is very interesting even though I don't know very many details. If I could add something to the fpGUI programs on this page that might be interesting: http://www.turbocontrol.com/easyfpgui.htm

Regards, Paul Breneman www.TurboControl.com - Hardware and software development services - Educational programming project for environment monitoring - Information on using FreePascal for embedded systems

Reply by email

Sven Barth
to Fred van Stappen: The thing is that i discover AT-SPI one week ago. Somebody tell me that he (his factory)…
Fred van Stappen wrote
But the magic of Pascal is his clear human-like language. So, i think Pascal should be a perfect language for deficient people. ( i do not want to imagine how difficult it must be for those persons to develop in C, even if the C compiler is AT-SPI enabled.)

Just in case you are thinking in this direction: the compiler itself will never (at least not in the foreseeable future) support assistive technology, because the compiler's dependencies are kept at a minimum (the compiler requires only the units in the RTL directory; and on more or less every system except Mac OS X no C library is required either). If you want to make the compiler accessible for people with disabilities, then you'll need to write a wrapper around it which could for example utilize the "-vq" option to display a message id in front of each message the compiler writes.
This does of course not mean that applications compiled using FPC can not support assistive technologies, just that the application "fpc" won't.

Regards,
Sven

Reply by email

Fred van Stappen
to Paul Breneman: I'd like to see Free Pascal used more for "factory" (industrial) work and for the last…
even though I don't know very many details. If I could add something the fpGUI programs on this page that might be interesting: http://www.turbocontrol.com/easyfpgui.htm

Do you know assistive technology ?
The easier way to begin is to (here example for Linux Ubuntu ) :
- in console : orca
- load lazarus and ear the result.

You could also only use console to test it.

Reply by email

Fred van Stappen
to Sven Barth: Just in case you are thinking in this direction: the compiler itself will never (at least…
then you'll need to write a wrapper around it which could for example utilize the "-vq" option to display a message id in front of each message the compiler writes.

Ones i get the trick how to link the compiled app with at-spi (console or LCL or fpGUI) , im sure it gonna be a easy game ( i hope ;) ) to do the wrapper who display the message the compiler write into at-spi.

Reply by email

Fred van Stappen
to Paul Breneman: I'd like to see Free Pascal used more for "factory" (industrial) work and for the last…
I'd like to see Free Pascal used more for "factory" (industrial) work

Maybe assistive technology (AT) could be very useful in industry too. Imagine a program who commands some machine. It could be that in the local there is not good light, that the screen is difficult to read, so AT can "speaks" the command entered, much safer for the user...

Reply by email

Fred van Stappen
to Fred van Stappen: Ones i get the trick how to link the compiled app with at-spi (console or LCL or fpGUI) ,…
then you'll need to write a wrapper around it which could for example utilize the "-vq" option to display a message id in front of each message the compiler writes.

Hello everybody.

I have finish the first part of sak (speecher assistive kit) for fpc. LCL and fpGUI are now totally "assistivilized".
See here :

Now i attack the biggest part, do fpc-self assistived.

Reply by email

Sven Barth
to Fred van Stappen
Fred van Stappen wrote 13 lines
>then you'll need to write a wrapper around it which could >for example utilize the "-vq" option to display a message id in front of >each message the compiler writes. Hello everybody. I have finish the first part of sak (speecher assistive kit) for fpc. LCL and fpGUI are now totally "assistivilized". See here : >> http://fredvs.github.io/sak/ Now i attack the biggest part, do fpc-self assistived.

Maybe you should now start a new thread for this, as it is still linked to the "Synchronize(dummyproc) with Linux" thread. ;)

Regards,
Sven

Reply by email

fredvs
to Fred van Stappen: Hello everybody. I have finish the first part of sak (speecher assistive kit) for fpc.…
Now i attack the biggest part, do fpc-self assistived.

Hello.

This is a answer to a old topic... (2013 already !).

Finally, it is done, fpc is assisted ;-)

Via ideU, fpc-output-messages can be voice-listened too.

=> https://github.com/fredvs/ideU/releases

Fre;D

-----
Many thanks ;-)

View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Synchronize-dummyproc-with-Linux-tp5714475p5723509.html Sent from the Free Pascal - General mailing list .

Reply by email