darnocian

Another related project, although C + Linux based, https://swtch.com/libtask/ has related concepts for event driven apps. Some concepts overlap with Golang.

I appreciate the conceptual difference between stackfull vs stackless coroutines. Fibers are stackful, where for stackless, we would need the compiler to weave in state management support for the yield/await type behaviour efficiently as done in many other languages that have the feature. Stackful has to save the stack when context switching, where the stackless has minimal state to save. I think without having language features, and trying to emulate the behaviour is probably only achievable with fiber like apis, be it less efficiently. The Gor article does provide good references / motivations as to why use is not encouraged. The scalability, performance and maintainability aspects ultimately dictate how useful something is in the long run. Needless, I still find it an interesting space and something to play with.

I've seen it happen as well. Sometimes doing a clean build and clearing/resetting the breakpoints will sort the issue out.

I have a few points: 1. it may be easier to use the Appercept AWS SDK. You don't need to bring Python into the picture in order to use it. Understandably, the SDK is currently only available in Delphi Enterprise. 2. in the code above, as you are downloading binary, I'd say it would be easier just write to file from python, and then read it back in from Delphi. I have not checked the marshalling code in the Py4D layer, but I assume that is what you are after. It depends on how you intend to use it, if the file is really big, do you want the whole thing in memory? 3. in python, I think you could also do and in delphi, I suspect this might mean there could be 2 copies of the byte array in memory temporary, which may not be ideal. disclaimer: I havn't tested the above, but guessing it may get towards the right direction.

@David Schwartz The approach of placing some middleware in front of the database is definitely better. The benefit of the approach vs direct db access is that you are likely to have more options in terms of scalability and support, and ability to centralise business logic. If you define the service contract well, you can change the implementation of the backend, as long as you don't break the contract, and all your clients can continue working. From a scalability perspective, you can easily put a load balancer in place to front multiple servers. When it comes to the db, you could have multiple read replicas with the backend server spreading the load between them, if your system is more read heavy. Anyways, it all depends on the problem you have, but having a service offering does give you options. It can become a pain if you have multiple clients (say desktop, web, mobile) having to implement business logic - one could get out of date because of a bug and management forgot to replace the contractor that was last working on that client that everyone forgot about. 😉 Further, you also have away of measuring usage, as you can enable logging, whereas with direct access to a db, you would need to query db logs or something. Further, the art of the service contact is how much data is in a request/response, do you make lots of small calls, or do you make one big one, etc... all depends on the problem. So with Google Firebase DB, I've seen mobile clients connect directly to it. Many companies have found this attractive in terms of simplicity, as an object store, it is easy to add / query items. However, I've seen issues where initially people get excited as it is so fast just accessing the db directly. then the pain creeps in there are different clients that have implemented the business logic internally. Anyways, you have to be careful about the use case and the problem being solved. Typically a cloud functions (like an aws lambda) could also linked to an endpoint to wrap business logic. I havn't tried using Firebase from TMS, so can't comment, but google essentially exposes the nosql db like a rest api (https://firebase.google.com/docs/reference/rest/database) So all the scalability and separation between implementation is handled by google probably in ways I've described, and hidden to the end user / developer. In my opinion, it is still a db store, so I'd still prefer to with front business layer or something vs going directly in. in my opinion, it is definitely useful to create the abstraction of having a service to front the db / storage ecosystem. don't expose the sql or whatever the underlying storage query language directly to the user, as you are then you are exposing internals and likely to have problems later where some friendly guy sends a 'drop table transactions' or something. 😉

sorry, I forgot the JavaClass before the .init 😉

Brian Long made a nice video on accessing Android APIs... Jim McKeeth also wrote an article which referenced the above: http://delphi.org/2014/07/custom-classes-dex/ On the various classes, you may note there are init() methods. these map onto the Java constructors (similar concept to Delphi constructors). from the app.java, I think you need to map over mSM62K2DriverApi and mMxFingerAlgAPI to Delphi fields on your form, something like: and then initialize them : then you should be able to reference the methods you are after.

I do find the mixed response in this thread really interesting. When I raised the RSP, Brian Long, an long time Delphi guy, asked if I had tested the routines and I said I'd provide an example test project. Most missed the intent to facilitate completeness as I did not labour that point too much. I thought providing the missing routines and tests is something that could be useful to to anyone else that was curious/explorers/prototypers, etc. I agree, 99.9% of coders will never need to go near this stuff. Open question - should there be a blanket ban on experiments or using stuff that nobody else does because it is deemed obsolete (g*d, how many times have I heard that about Delphi/Pascal). Just putting it out there....

For reference, I raised https://quality.embarcadero.com/browse/RSP-40056 in Nov 22 to include the missing fiber functions.

@Remy LebeauYes, I've seen Raymond Chen's blog. However, in many languages, coroutines are popular. Fibers is one way to implement them. Generally, I would say the argument would be that most people would not use them directly, but possibly a wrapper or language feature would utilise fibers to provide some interesting behaviour. I would say, it is pointless including fiber functions in the windows unit without these as they provide context around whatever needs to be done. Agreed - nobody but me has missed probably them as they have been excluded for so long, or nobody bothered raised a QP ticket for the omission. Unfortunately, Delphi is not in the list of languages supporting coroutines either. ;(

Hi I created a ticket a while back on Quality Portal for some missing Windows SDK functions for Fibers. I created a small test project to illustrate them working in https://github.com/sempare/sempare-delphi-fiber-generator. For those that don't know, fibers essentially are light weight threads, where context switching between fibers is managed by the developer and not by the OS, as is done with threads. It can be complex to get your head around them if you are not familiar with them. For a more detailed discussion, here is a nice article: https://nullprogram.com/blog/2019/03/28/ and https://learn.microsoft.com/en-us/windows/win32/procthread/fibers. I think the reason they were omitted in the Delphi Windows unit is because the tool that did the main conversion of the Windows SDK functions was working with normal C functions, where the missing functions I've included were defined as C macros. From a Delphi perspective, GetFiberData annd GetCurrentFiber are available in the unit https://github.com/sempare/sempare-delphi-fiber-generator/blob/develop/src/Sempare.Win32.Fiber.pas for win32 and win64. In the project, the unit https://github.com/sempare/sempare-delphi-fiber-generator/blob/develop/src/Sempare.FiberGenerator.pas contains a TGenerator<T> which switches between the procedure producing values and the main method that is consuming them. Here is an example of it in use with a fibonacci generator. So what is going on here.... A producer is a procedure that must call Yield(value). So we know that with Fibonacci, f(0) =1, f(1) =1, f(n) = f(n-1) + f(n-2). Rather than having a recursive routine, the producer method simply Yields the values appropriately. Yes, it looks like the method will never stop. That doesn't matter. Once the method has a value to yield, the context is switched back to the main bit of code that is requesting the value ... that where we have: As mentioned, this is just a simple demo of using fibers. Another project I had that has a bit more complex utilisation of fibers was for async IO on sockets - the principle was to make async calls with call back functions appear synchronous, which is what most people are more comfortable with. Even though most people will never need to use the fiber methods directly as I illustrated above with the TGenerator example, it is quite a powerful tool in the toolbelt.

Hi all, I'm pleased to announce the new release (v1.7.2) of the Sempare Template Engine. This release includes: NEW manage/unmanage methods for managing objects created while the template is being evaluated. Template Engine Playground enhancements (now using the Carbon theme, shows template evalution time in ms, extract variables form a template) json/map like variable support FIX removed caching of TRttiMethod to ensure virtual methods are supported correctly fixed regression of TValue type coercion Older release notes can be viewed on the releases page. Have fun.

That looks like your file system may be corrupted if a .pas is opening that way. Worth looking at a backup (hopefully you have external version control like github). Worth running a chkdsk on your drive and check other sources too that you may rely on.

Hi all, I'm pleased to announce the new release (v1.7.0) of the Sempare Template Engine. It has been a while, and thought I'd just remind any users here about the project. Also included are some demos... for apps in general, there is a new helper class TTemplateRegistry, which should make things much easier to just get going and supports template reloading without restarting the app and can load templates from file, resources, or custom a loader. This takes some of the grunt work out of working with templates, besides just using them. More information is available in the docs on the repo. Some simple examples are provided to illustrate server side scripting. If you have any suggestions, or see any gaps, please feel free to provide comments on the issue tracker. - Demo using the Horse framework - Demo using WebBroker standalone console app New features: - improved support for comments - extends/block template support - improved whitespace removal - renamed demo app to Sempare Template Engine Playground - a useful tool for testing language features / templates. - added the Sempare.Template.RCGenerator project to help with creating resource rc files by scanning directories. - support multiple statements in a script block. e.g. <% print('a'); print('b') %> - additional context configuration - improved docs (improved navigation and added railroad diagrams to illustrate the grammar) Older release notes can be viewed on the releases page. Have fun.

Maybe better to have a callback function that can be used for debugging. That would be controllable by the application, UI or console. e.g. in the DLL, have a proceudure SetDebugCallback(const ACallback:TDebugCallback); where TDebugCallback = procedure (const AMessage: PChar); stdcall; Note: use PChar and not a string (maybe be even more explicit like PWideChar, PAnsiChar). That way, in the application, console app could do writeln, where the UI app could show a dialog, add to a list, whatever... Also, I wouldn't trust sending a Delphi managed type across a DLL boundary. It limits what type of apps can consume and use the function as they would need to emulate the string interface, knowing the internals of the type, where using zero terminated strings is supported by the Delphi compiler.