Re: [fpc-pascal] WebAssembly Target
On 15.03.2017 17:58, Karoly Balogh (Charlie/SGR) wrote: Well, "degree of success" is relative, ... Anyway, it's great to know that you are watching the proceedings regarding WebAssembly, and already did some effort to get started Just for enhancing your motivation :-) (of course this issue is more like a project related to the Lazarus or mse designers, but you are going to pave the way) : IMHO this will be a great method to create (pure Pascal) applications that are split in a server based part and a browser based part. A very desirable way to do so would be to use a GUI based IDE (such as Lazarus or mse) to create and test an application running locally, and then define "split points" and use some kind of standard communication protocol (i. e. rpc) library to split it up appropriately - just with some definitions, without really writing any additional code. While the perfect splitting points of course depend on the application you are doing, one "simple" way would be to provide a server based application with a browser based remote GUI. (This might usually be called "Rich Internet Application".) I know that mse features a tool called "ifi" to convert a normal "local" application into a remote-controlled application with a remote GUI. Here, the GUI part is an application created by mse/fpc, and able to connect to any backend application done with "ifi". Building on top of "ifi" it might be possible do have the "ifi-Browser" run in a Web-Browser using WebAssembly. ms like a very viable goal to me. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On 16.03.2017 11:46, Graeme Geldenhuys wrote: Umm, didn't they say the exact same thing about Java Applets, No idea Flash, While it's depreciated right now it did last for a long time and was _very_ useful. Silverlight While technically it did look nice, it was a single-company thingy and doomed as this company did not succeed with taking over on the mobile market. etc. :) As Microsoft, Google, and Mozilla had been in the boat it looked a lot more promising. I guess time will tell, but if history is anything to go buy, security issues *will* pop up. Hopefully they did consider this in the textbook -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On Thu, 16 Mar 2017, Michael Schnell wrote: On 15.03.2017 17:58, Karoly Balogh (Charlie/SGR) wrote: Well, "degree of success" is relative, ... Anyway, it's great to know that you are watching the proceedings regarding WebAssembly, and already did some effort to get started Just for enhancing your motivation :-) (of course this issue is more like a project related to the Lazarus or mse designers, but you are going to pave the way) : The way is already paved. In fact, there is an alternate approach, transpiling pascal to Javascript. It's much farther ahead than the webassembly target, already produces programs running in the browser and the first web-based components are already being developed using this approach. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
Hi, On Fri, 17 Mar 2017, Michael Van Canneyt wrote: > In fact, there is an alternate approach, transpiling pascal to Javascript. > > It's much farther ahead than the webassembly target, already produces > programs running in the browser and the first web-based components are > already being developed using this approach. I believe these will be complimentary solutions in the end, one will be better for certain things than the other, with a lot of overlap, of course. I think the transpiler might be better for developing unique front-end solutions in Pascal for the web, the WebAssembly compiler might be better to bring existing large chunks of code to run on the web, with minimal modifications, and for performance critical things. But only time will tell. :) Charlie ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On Fri, 17 Mar 2017, Karoly Balogh (Charlie/SGR) wrote: Hi, On Fri, 17 Mar 2017, Michael Van Canneyt wrote: In fact, there is an alternate approach, transpiling pascal to Javascript. It's much farther ahead than the webassembly target, already produces programs running in the browser and the first web-based components are already being developed using this approach. I believe these will be complimentary solutions in the end, one will be better for certain things than the other, with a lot of overlap, of course. I think the transpiler might be better for developing unique front-end solutions in Pascal for the web, the WebAssembly compiler might be better to bring existing large chunks of code to run on the web, with minimal modifications, and for performance critical things. Fully agreed, and the "unique front-end solutions in Pascal for the web" is the intended target. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On Thu, 16 Mar 2017 11:14:17 + Graeme Geldenhuys wrote: > And I am pleasantly surprised! :) That demo worked perfectly on my > system. Sound, animation, graphics all silky smooth. Impressive indeed. If running a 3 year old iOS Demo in a browser when we have seen Unreal Tournament 3 being playable there 4 years ago is impressive is debatable. For me the impressive thing is that FireFox with WebAssembly manages to show the same performance as Chrome without it. Having them run side by side both fullscreen I can see no performance difference at all. Perhaps the JS side is doing so little that it hardly matters (as it should be, when doing WebGL you want to do as much on the GPU as possible). First benchmarks indicate that there isn't much of a performance increase with the current WebAssembly implementation over pure JS anyway. The benefit is that you can 'run C code' in the browser and that's currently it. Having a WebAssembly target for FPC would surely be nice (more options) but hardly a game changer currently. In my little experience with WebGL the JS performance was never that big of a problem but getting lots of data into the browser without the transfer being super slow or the browser consuming alot more memory than it should. R. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On 2017-03-17 14:57, Reimar Grabowski wrote: > Perhaps the JS side is doing so little that it hardly matters (as it > should be, when doing WebGL you want to do as much on the GPU as > possible). A very good point. It was probably all down to WebGL (ie: your GPU) doing all the work. Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Thread Variables Initial Values
Hello, The documentation is not clear about the initial values of thread variables: *"If threads are used then a copy is made for each thread (including the main thread). Note that the copy is made with the original value of the variable, not with the value of the variable at the time the thread is started."* So, if i declare a threadvar: threadvar MyObject: TObject; What will be the initial value of the variable when each thread uses its copy for the first time? Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threadvar member field
On 16.03.2017 19:38, African Wild Dog wrote: I have a class where its instances are shared between multiple threads. How can I declare one variable per instance per thread? Does this really make sense ? Accessing threadvars (in fpc) costs a lot more CPU cycles (i.e. involves an OS call) than accessing normal variables. Supposedly the way to go is to do per-thread instances of a class, that might reference the other classes you want to instantiate. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thread Variables Initial Values
On Fri, 17 Mar 2017, African Wild Dog wrote: Hello, The documentation is not clear about the initial values of thread variables: *"If threads are used then a copy is made for each thread (including the main thread). Note that the copy is made with the original value of the variable, not with the value of the variable at the time the thread is started."* So, if i declare a threadvar: threadvar MyObject: TObject; What will be the initial value of the variable when each thread uses its copy for the first time? Nil. What exactly is not clear about the documentation ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threadvar member field
Hi, On Fri, 17 Mar 2017, Michael Schnell wrote: > Accessing threadvars (in fpc) costs a lot more CPU cycles (i.e. involves > an OS call) than accessing normal variables. This is actually entirely platform specific. The underlying implementation of threadvars is very different for each platform, and highly depends both on the CPU arch and the OS. On some platforms, threadvars are barely slower than normal ones, other platforms have the large penalty you're talking about. I agree though that it's still wise to count on the worst case scenario though. Charlie ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt wrote: > In fact, there is an alternate approach, transpiling pascal to Javascript. > > It's much farther ahead than the webassembly target, already produces > programs running in the browser and the first web-based components are > already being developed using this approach. What is the role of those components ? Reading this thread I was thinking would be nice (easier to work) ) to have access to browser components via a fpc lib. Something like fcl-browser-facilities (terrible name, I know), where you could simple calls to DOM parts. Whether this is already in fcl-js, sorry, I didn't knew about it.. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On Fri, 17 Mar 2017, Daniel Gaspary wrote: On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt wrote: In fact, there is an alternate approach, transpiling pascal to Javascript. It's much farther ahead than the webassembly target, already produces programs running in the browser and the first web-based components are already being developed using this approach. What is the role of those components ? You'll design a web app in the lazarus IDE (or Delphi IDE, for that matter). The app will be compiled to Javascript. Current thinking is that that there will be 2 "modes": - "Free" Mode, where the CSS will determine the actual runtime look. The IDE will just create the DOM structure. - "Exact" mode, where the app will look in the browser as it looks in the IDE. the necessary CSS will be generated for this. In both modes of course the IDE and object inspector will be used to create event handlers and whatnot in Pascal... But this is all still under heavy development. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On Fri, 17 Mar 2017, Daniel Gaspary wrote: On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt wrote: In fact, there is an alternate approach, transpiling pascal to Javascript. It's much farther ahead than the webassembly target, already produces programs running in the browser and the first web-based components are already being developed using this approach. What is the role of those components ? Reading this thread I was thinking would be nice (easier to work) ) to have access to browser components via a fpc lib. Something like fcl-browser-facilities (terrible name, I know), where you could simple calls to DOM parts. Forgot to say that there will of course be some classes to manipulate the DOM at will. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
On Fri, Mar 17, 2017 at 2:55 PM, Michael Van Canneyt wrote: > Forgot to say that there will of course be some classes to manipulate the > DOM at will. Thank you, Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thread Variables Initial Values
2017-03-17 13:09 GMT-03:00 Michael Van Canneyt : > > Nil. > > What exactly is not clear about the documentation ? > The documentation says ".. Note that the copy is made with the original value of the variable ..". But, whats is the original value? I think the documentation should be clearer about the initial values of thread variables. From what i I understand, the value is default(T) for all threads. So, the documentation should mention that. Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threadvar member field
2017-03-17 5:50 GMT-03:00 Michael Schnell : > On 16.03.2017 19:38, African Wild Dog wrote: > >> I have a class where its instances are shared between multiple threads. >> How can I declare one variable per instance per thread? >> > Does this really make sense ? > > Accessing threadvars (in fpc) costs a lot more CPU cycles (i.e. involves > an OS call) than accessing normal variables. > > Supposedly the way to go is to do per-thread instances of a class, that > might reference the other classes you want to instantiate. > > I have huge collection of objects (abot 1 million) in memory so if i go with per-thread instance it will consume the entire memory ram. I will have to redesign my classes =(. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Hash List
Hello, Ia there any hash list implementation in free Pascal? Ghashmap has no documentation. Is it stable for production use? Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hash List
On Fri, Mar 17, 2017 at 8:29 PM, African Wild Dog wrote: > Hello, > > Ia there any hash list implementation in free Pascal? > Hello, Please take a look at these examples: https://github.com/graemeg/freepascal/tree/master/packages/rtl-generics/examples and in this wiki page: http://www.freepascal.org/docs-html/3.0.0/fcl/contnrs/tfphashlist.html > Ghashmap has no documentation. Is it stable for production use? > Some info: https://www.mii.lt/olympiads_in_informatics/pdf/INFOL101.pdf -- Silvio Clécio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hash List
Il 18/03/2017 00:29, African Wild Dog ha scritto: Ia there any hash list implementation in free Pascal? The IniFiles unit (fpc/packages/fcl-base/src/inifiles.pp) provides a THashedStringList (descendant from TstringList) which I'm using reliably since many years. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hash List
Thanks for your reply Giuliano, Silvio. To be more specific, i need a generic hash map similar to the Delphi's TDictionary. It seems THashmap from the ghashmap unit is the most close to TDictionary. Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hash List
You're welcome. :-) Notice the first link I've passed is exactly showing the TDictionary, recently added to FPC: https://github.com/graemeg/freepascal/blob/master/packages/rtl-generics/src/inc/generics.dictionariesh.inc#L534 . You should take a look at that. :-) On Sat, Mar 18, 2017 at 12:54 AM, African Wild Dog wrote: > Thanks for your reply Giuliano, Silvio. > > To be more specific, i need a generic hash map similar to the Delphi's > TDictionary. > > It seems THashmap from the ghashmap unit is the most close to TDictionary. > > Regards > -- Silvio Clécio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
