Jump to content

Andrea Raimondi

Members
  • Content Count

    52
  • Joined

  • Last visited

Posts posted by Andrea Raimondi


  1. 9 hours ago, David Heffernan said:

    Whilst you can, this doesn't feel like a great idea. It's one thing returning a tuple in a language like Python with support for unpacking. But a Delphi dynamic array should be used for arrays, things where each item is a different value of the same thing. That's not the case here. They are two distinct things. 

     

    Use a record, or two out params. 

    I do not necessarily agree with this. I agree on the fact that a record would work better for several reasons and that a generic list has a number of disadvantages; however, if the function is eventually going to have multiple values, then a typed list (i.e. a generic but with a concrete type) would probably work better. However, if changes are infrequent and/or the values must be easy to identify then a record is absolutely the way to go.

    I would never use a dynamic array because it's too easy to mis-identify things. 


  2. I would be very interested in something like this if there were clear demos and examples on how to use this properly.

    I would be especially interested in "working demos" such as UI pieces etc. I know you can do this with TMS and JavaScript or a host of other options (such as Smart Pascal or Quartex) but they all revolve around the very insecure NodeJS and I want nothing to do with that. 

     

    So... something that doesn't use that would be welcome in my mind. 


  3. Hi!

     

    My opinion on the topic stems not from the use of the APIs but rather from being a regular target, in Europe, of dodgy-behaving companies. 

    To understand the problem trying to be solved here, consider this:

     

    Oftentimes, when you visit a site in the EU, you get a popup saying "We care about your privacy!": those are indeed usually the worst offenders. 

    What they will do is to comply where they must (for example offering a "Reject all" button on the screen) but you have to pay attention because if you peek into the legittimate interest you will see everything active. 

    Therefore, by "saving" without looking into the legittimate interests, you will still be tracked just as before and the ads will reflect that (but with caution, because they're not stupid!). 

     

    Yet there is more: if you then also go into the "Third Party" tab (where available) occasionally you will find some still active despite rejecting everything. 

     

    This is the landscape Apple is unleashing the Tracking API in. This is why the descriptions are vague: because providers go out of their way to screw you over so they need wiggle room to nuke all of them from orbit.

     

    As for the idea that Apple aims at keeping the tracking data to itself: it's possible, but I am not sure that is the real goal. I think recent scandals have shown that robust tracking is detrimental to everyone and Apple buyers are, on the whole, higher worth people who have probably expressed an appetite for tracking-less phones and apps. It's still possible that they will track you and monetize that, but I think it's not necessarily true. 


  4. 12 hours ago, mvanrijnen said:

    It's about: GitHub - StockSharp/StockSharp: Algorithmic trading and quantitative trading open source platform to develop trading robots (stock markets, forex, crypto, bitcoins, and options).

     

    I want (maybe) use it for a custom trading bot,  but it's Russian, so people heard about this, can it be trusted?

     

    Hi!

     

    I don't know that any specific repo can be trusted when it comes to BTC etc. without intense static analysis be it Russian or not. 

    Also keep in mind that GitHub itself has been subject to a mining attack whereby a pretend-NodeJS instance was available and executed which would perform crypto mining leveraging GitHub servers, so... kinda shady the whole thing whoever does it. 

    But this library is developed in C# so static analysis is an option and I think there are several products that can do it. 

     

    Static Analysis is your first line of defense, especially if you can establish "shady patterns" to look for. 

     

    I am muchly more worried about situations where, say, the repo is on Russian/Chinese servers and with Internet-related laws that are questionable at least, if not downright awful. 

     

    Static analysis is your friend, mate, use it!

    • Like 1

  5. Hello!

     

    Simple class:

     

    {$RTTI EXPLICIT METHODS( [vcPrivate,vcProtected, vcPublic,vcPublished] )
                      PROPERTIES( [vcPrivate,vcProtected, vcPublic,vcPublished] )
                      FIELDS ( [vcPrivate,vcProtected, vcPublic,vcPublished] )}
      TTestClass = class
      private
        FTestProperty: Integer;
        procedure DoSomething;
        function Test: Boolean;
        procedure SetTestProperty(const Value: Integer);
      public
        procedure DoSomethingPublic;
        property TestProperty : Integer read FTestProperty write SetTestProperty;
      end;

    Trying to access private members via this code:

    RTTIUtils.GetFields( AnObj, Fields );

    Which is defined like so::

    procedure TClassRTTIUtils.GetFields(AnObject: TObject;
      var Fields: TArray<TRttiField>);
    begin
      Fields := Ctx.GetType( AnObject ).GetFields;
    end;

    Ctx is a TRTTIContext (naturally, but worth mentioning).

     

    10.4.2 raises an exception and I am not really sure why. 

     

    I must be missing something obvious but can't see what.

     

    Are there odd project options I have to set? I have browsed through them but can't find anything that will make me go "here it is!". 

     

    Thanks!


  6. On 1/16/2021 at 9:27 AM, Dalija Prasnikar said:

    That is fine. 

     

    Point is that System.Messaging is not thread safe. If you are writing multi-threaded application and you need to communicate using some messaging system, then System.Messaging will simply not work in such conditions. You can still use it to send messages to the main thread, but you need to synchronize messaging code, which is not always viable solution.

     

    In multithreaded applications, you will need thread safe messaging system that is also capable of posting messages to some message queue.

    Hi,

     

    Multithreaded applications - in my view - should be made with appropriate libraries such as OmniThread, because you reap all the benefits of multithreading while keeping (most of) your sanity 😄 

    The problem remains that if you send async messages in a multi-threaded application you very easily end up not knowing how that message came about in the first place because, you know, thread debugging sucks and not just in Delphi.

    Given that a message may be coming from a different threading context, things get wild very quickly. 

     


  7. 16 hours ago, vfbb said:

    @Andrea Raimondi

    The full explanation is on the github page. See this part:

     

    "The problem

    Delphi has its own messaging system (System.Messaging.pas) that works well but is totally synchronous and thread unsafe. In multithreaded systems we always need to communicate with other classes, sometimes synchronously, sometimes asynchronously, sometimes synchronizing with the mainthread (in the case of the UI), and doing this without a message system (communicating directly) makes the code large and complex, prone to many bugs."

     

    I read that and I still disagree 😄 

     

    I like System.Messaging because it's synchronous and you need to plan the message flow. I am not saying that yours is a bad solution, all I am saying is that I like synchronous solutions such as Systerm.Messaging better on philosophical  grounds. Async stuff is much harder to debug and will often not return enough on your investment to make up for the added difficulty in debugging and reasoning about things. 

     

    I want to be able to follow things along so that I know that from Step A we go into Step B and not that Step XYZ gets in the middle without any apparent reason 😄 


  8. The other big advantage of this approach is maintenance: by doing this you only need to search for the message class and you will not miss any code and it's easier to pick up for newcomers to the project.

     

    This approach has all kinds of advantages that become clear as soon as you start using it. 

     

    You can also split the code initiating the message from that which receives it so you can have different people working on the same feature from two different angles and if a message cuts across features everyone can just add a handler and be done with it. What happens to the handlers becomes a problem you don't have to deal with. 


  9. 11 hours ago, Attila Kovacs said:

    @Andrea Raimondi

    At first sight this hocus-pocus has not much to do with System.Messaging at all and could be be easily create the same with this lib.

     

    By the way, what do you mean with

    Are you writing message driven apps?

     

    By the way 2

    
    initialization
    begin
      MsgMgr := TMessageManager.DefaultManager;
    end;

    What is your purpose with begin/end? Is this also some readability thing?

     

    Hi,

     

    Yes it may be redone, probably, but it would go against the "current" of what that library is trying to accomplish and it would be unnaturally convoluted to do it. 

    And yes, whenever I can, I write message driven apps. I find reasoning about message flows much easier than using events and such. I can also share code much more easily and because one of my rules is that "Messages often are features" that allows other people to reason about the flow and the behaviour in much easier to understand ways. The final advantage is that such architecture fosters statelessness which means you have much broader reach and need to pay attention to what you do 😄 

     

    The purpose there is not so much readability (which is part of it) but also consistency. I find lack of begin/end pairs in initialization/finalization very bad because you don't get the lines and you can't easily collapse them (please do give it a try: both work when you use begin/end). Moving things is also a lot easier for you could - for example - create a new InitYaddaYaddaYadda and just cut and paste the whole block. Finally, keep in mind that this is an example and chances are thart in my actual prologue/epilogue there mayt be a lot more stuff. 

    • Like 2

  10. Hi!

     

    Personally, I like System.Messaging because it allows you to do things like this:

     

    unit Unit3;
    
    interface
    
    uses System.Messaging;
    
    Type
    
      TNofification = class( TMessage )
      public
        class procedure Notify;
      end;
    
      TNotification<T> = class( TMessage<T> )
      public
        class procedure Notify(Value: T);
      end;
    
    var MsgMgr : TMessageManager;
    
    implementation
    
    { TNofification }
    
    class procedure TNofification.Notify;
    begin
      MsgMgr.SendMessage( nil, Self.Create );
    end;
    
    { TNotification<T> }
    
    class procedure TNotification<T>.Notify(Value: T);
    begin
      MsgMgr.SendMessage( nil, Self.Create( Value ) );
    end;
    
    initialization
    begin
      MsgMgr := TMessageManager.DefaultManager;
    end;
    
    end.

    Now what you can do here is subclass the right notification and simply use it: 

     

    unit Unit3;
    
    interface
    
    uses System.Messaging;
    
    Type
    
      TNofification = class( TMessage )
      public
        class procedure Notify;
      end;
    
      TNotification<T> = class( TMessage<T> )
      public
        class procedure Notify(Value: T);
      end;
    
      TNotifyLoggedUsers = class( TNotification<integer> )
      public
        class procedure NotifyNumberOfLoggedUsers( Value : Integer );
      end;
    
    var MsgMgr : TMessageManager;
    
    implementation
    
    { TNofification }
    
    class procedure TNofification.Notify;
    begin
      MsgMgr.SendMessage( nil, Self.Create );
    end;
    
    { TNotification<T> }
    
    class procedure TNotification<T>.Notify(Value: T);
    begin
      MsgMgr.SendMessage( nil, Self.Create( Value ) );
    end;
    
    { TNotifyLoggedUsers }
    
    class procedure TNotifyLoggedUsers.NotifyNumberOfLoggedUsers(Value: Integer);
    begin
      Notify( Value );
    end;
    
    initialization
    begin
      MsgMgr := TMessageManager.DefaultManager;
    end;
    
    end.

    Now what you can do is to call NotifyLoggedUsers directly in a way such as:

    begin
      TNotifyLoggedUsers.NotifyNumberOfLoggedUsers(Users.Count);
    end;

    This is *very* interesting, powerful and readable. 

    The other big plus is that being synchronous it allows you to reason easily about message flows and you can build up programming documentation using diagrams that can be used and understood by sales and other parties as well. 


  11. Hi!

     

    As far as I know, those properties deal with different monitor sizes. 

    Suppose that you're developing on a 1024x768 monitor, then a new colleague comes on board who's on a 1900xyaddayaddayadda. 

    That's where the explicit properties kick in: now they are set because the monitor has a different resolution and if any changes in size are made to adjust for this, then the explicit properties will follow along.

    It's basically a way to have usable forms and data modules both at design and runtime for both developers and customers. .

     

    But that's my understanding and I may be wrong.


  12. Hi!

     

    This is my current DFM:

     

    object Viewport3D1: TViewport3D
      Align = Top
      Size.Width = 640.000000000000000000
      Size.Height = 100.000000000000000000
      Size.PlatformDefault = False
      object Text3D1: TText3D
        WrapMode = Fit
        Position.X = 325.000091552734400000
        Position.Y = 44.999977111816400000
        Position.Z = 0.000061035156250000
        RotationAngle.X = 198.409103393554700000
        RotationAngle.Y = 95.915130615234380000
        RotationAngle.Z = 85.144851684570320000
        Width = 59.589870452880860000
        Height = 385.819519042968800000
        Depth = 17.276718139648440000
        Projection = Screen
        VisibleContextMenu = False
        TwoSide = True
        ZWrite = False
        Text = 'Snap&Share'
        Flatness = 1.000000000000000000
        Sides = [Front, Back, Shaft]
        Quanternion = 
          '(0.118859842419624,-0.110193893313408,-0.70152872800827,-0.69396' +
          '6567516327)'
      end
    end
     

    My final goal is:

    1) Have a clearly 3D text, i.e. users can see it's 3D

    2) When there's an action performed by the user (i.e. for example the click of a button) I want this text to rotate. 

     

    So, what I want to obtain is a slightly inclined text that clearly shows it's already 3D as a first step. You know what I am talking about, right?

     

    Thanks!

     

    A


  13. Hello!

     

    I am sure I am doing something not very smart somewhere (or I just don't quite understand how 3D works, which is possible!) and my 3D text looks terrible and I don't know how to make it look right 😄 

     

    Please find the currently really bad text attached. 

     

    Anybody knows why it's that bad and not showing properly?

     

    Thanks!

    Text3D fail.PNG


  14. 15 hours ago, pyscripter said:

    Where exactly do we disagree?  I started by saying the features are great.  But if xml processing is a performance bottleneck you can improve performance drastically (see below) by accessing the underlying implementation directly with minimal changes to your code, since implementations follow the standard DOM interfaces.

    We disagree on the notion that the performance is an issue 🙂 

    I think it's not, given how much stuff you can do out of the box. 

     

    I would also like to point out that OXML is quite a neat library, we use it for importing Excel (xlsx ones) and it's awesome. 

    • Like 1

  15. I don't necessarily agree that the default XML document is bad, considering all the features that you get. I do agree that if it let you be faster but with access to fewer features than that might be a compromise that developers may be willing to make. And I think that other offerings basically take that approach: they don't necessarily give you everything and you compromise on that. 

     

    One thing that bothers me a little bit is that there seems to be no notion of using SAX processing which is probably much better suited to SVG than a full blown DOM. 

     

    This is why I don't necessarily agree with what you're saying. 

     

    A


  16. On 6/27/2020 at 9:13 PM, Darian Miller said:

    nSoftware has an E-Payment Integrator that supports Stripe:

    https://www.nsoftware.com/in/epayment/

    https://www.nsoftware.com/kb/xml/02191401.rst

     

    If you are interested, then I would suggest that you buy their full Red Carpet Subscription instead of a single component.  https://www.nsoftware.com/subscriptions/

    They have a rather large component set and they offer support for multiple languages.

     

    Talk to Irida Haznedar, my account rep and see if you can get a discount.  (sales@nsoftware.com)

     

    nSoftware is a highly recommended company.

     

    The problem I have with that company is that everything costs waaaaaay too much. I am a single developer and for now I am just exploring options.

×