home.social

#objectpascal — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #objectpascal, aggregated by home.social.

  1. 👏 Wow, finally! The world has been begging for yet another Object Pascal #compiler because, you know, the planet just can't function without one in 2023. 🚀 Let's celebrate the #reincarnation of a language most people haven't used since the 90s. #CuttingEdgeInnovation 🙄
    github.com/graemeg/blaise #ObjectPascal #Innovation #TechNews #HackerNews #ngated

  2. 👏 Wow, finally! The world has been begging for yet another Object Pascal #compiler because, you know, the planet just can't function without one in 2023. 🚀 Let's celebrate the #reincarnation of a language most people haven't used since the 90s. #CuttingEdgeInnovation 🙄
    github.com/graemeg/blaise #ObjectPascal #Innovation #TechNews #HackerNews #ngated

  3. 👏 Wow, finally! The world has been begging for yet another Object Pascal #compiler because, you know, the planet just can't function without one in 2023. 🚀 Let's celebrate the #reincarnation of a language most people haven't used since the 90s. #CuttingEdgeInnovation 🙄
    github.com/graemeg/blaise #ObjectPascal #Innovation #TechNews #HackerNews #ngated

  4. 👏 Wow, finally! The world has been begging for yet another Object Pascal #compiler because, you know, the planet just can't function without one in 2023. 🚀 Let's celebrate the #reincarnation of a language most people haven't used since the 90s. #CuttingEdgeInnovation 🙄
    github.com/graemeg/blaise #ObjectPascal #Innovation #TechNews #HackerNews #ngated

  5. 👏 Wow, finally! The world has been begging for yet another Object Pascal #compiler because, you know, the planet just can't function without one in 2023. 🚀 Let's celebrate the #reincarnation of a language most people haven't used since the 90s. #CuttingEdgeInnovation 🙄
    github.com/graemeg/blaise #ObjectPascal #Innovation #TechNews #HackerNews #ngated

  6. RE: oldbytes.space/@thelastpsion/1

    And the results are in!

    1. Pico C
    2. Rust
    3. Free Pascal
    4. Joint with Pico C++, MicroZig and Yarg.

    So, what am I going to do? Well, I'm leaning towards porting the existing Arduino C code to the Pico C SDK. I'm currently using one class for encapsulation and abstraction, but I could replace that with structs and static functions. I'm not a great C programmer, but I'm pretty comfortable with it, so it makes sense

    However, before I do that, I see a bigger challenge of getting a good setup without using VS Code. I've been using #NeoVim for a while now, and I'd like to get a comfortable setup using that on #Linux.

    So, I'm going to try to build Blinky projects for at least Pico C, Rust and Free Pascal, using Linux and NeoVim. Hopefully this will give me a better feel for how well these languages actually suit me. I've never done any Rust before, either, so that's going to be quite the learning curve!

    If I have time, I'm going to give Yarg a go, too, because I think the premise is really cool. If I'm on a roll, I'll try #MicroZig too.

    And if I really feel like I have the capacity, I'll port the code to one of these other languages.

    I'm acutely aware of all the other projects I've given myself to do, such as the SIBO SDK and other small Psion-related projects, not to mention $dayjob and $reallife. So we'll see how things go!

    #Pascal #FreePascal #ObjectPascal #RustLang #YargLang #RaspberryPiPico #PiPico #PiPico2 #RP2040 #RP2350

  7. RE: oldbytes.space/@thelastpsion/1

    And the results are in!

    1. Pico C
    2. Rust
    3. Free Pascal
    4. Joint with Pico C++, MicroZig and Yarg.

    So, what am I going to do? Well, I'm leaning towards porting the existing Arduino C code to the Pico C SDK. I'm currently using one class for encapsulation and abstraction, but I could replace that with structs and static functions. I'm not a great C programmer, but I'm pretty comfortable with it, so it makes sense

    However, before I do that, I see a bigger challenge of getting a good setup without using VS Code. I've been using #NeoVim for a while now, and I'd like to get a comfortable setup using that on #Linux.

    So, I'm going to try to build Blinky projects for at least Pico C, Rust and Free Pascal, using Linux and NeoVim. Hopefully this will give me a better feel for how well these languages actually suit me. I've never done any Rust before, either, so that's going to be quite the learning curve!

    If I have time, I'm going to give Yarg a go, too, because I think the premise is really cool. If I'm on a roll, I'll try #MicroZig too.

    And if I really feel like I have the capacity, I'll port the code to one of these other languages.

    I'm acutely aware of all the other projects I've given myself to do, such as the SIBO SDK and other small Psion-related projects, not to mention $dayjob and $reallife. So we'll see how things go!

    #Pascal #FreePascal #ObjectPascal #RustLang #YargLang #RaspberryPiPico #PiPico #PiPico2 #RP2040 #RP2350

  8. RE: oldbytes.space/@thelastpsion/1

    And the results are in!

    1. Pico C
    2. Rust
    3. Free Pascal
    4. Joint with Pico C++, MicroZig and Yarg.

    So, what am I going to do? Well, I'm leaning towards porting the existing Arduino C code to the Pico C SDK. I'm currently using one class for encapsulation and abstraction, but I could replace that with structs and static functions. I'm not a great C programmer, but I'm pretty comfortable with it, so it makes sense

    However, before I do that, I see a bigger challenge of getting a good setup without using VS Code. I've been using #NeoVim for a while now, and I'd like to get a comfortable setup using that on #Linux.

    So, I'm going to try to build Blinky projects for at least Pico C, Rust and Free Pascal, using Linux and NeoVim. Hopefully this will give me a better feel for how well these languages actually suit me. I've never done any Rust before, either, so that's going to be quite the learning curve!

    If I have time, I'm going to give Yarg a go, too, because I think the premise is really cool. If I'm on a roll, I'll try #MicroZig too.

    And if I really feel like I have the capacity, I'll port the code to one of these other languages.

    I'm acutely aware of all the other projects I've given myself to do, such as the SIBO SDK and other small Psion-related projects, not to mention $dayjob and $reallife. So we'll see how things go!

    #Pascal #FreePascal #ObjectPascal #RustLang #YargLang #RaspberryPiPico #PiPico #PiPico2 #RP2040 #RP2350

  9. RE: oldbytes.space/@thelastpsion/1

    And the results are in!

    1. Pico C
    2. Rust
    3. Free Pascal
    4. Joint with Pico C++, MicroZig and Yarg.

    So, what am I going to do? Well, I'm leaning towards porting the existing Arduino C code to the Pico C SDK. I'm currently using one class for encapsulation and abstraction, but I could replace that with structs and static functions. I'm not a great C programmer, but I'm pretty comfortable with it, so it makes sense

    However, before I do that, I see a bigger challenge of getting a good setup without using VS Code. I've been using #NeoVim for a while now, and I'd like to get a comfortable setup using that on #Linux.

    So, I'm going to try to build Blinky projects for at least Pico C, Rust and Free Pascal, using Linux and NeoVim. Hopefully this will give me a better feel for how well these languages actually suit me. I've never done any Rust before, either, so that's going to be quite the learning curve!

    If I have time, I'm going to give Yarg a go, too, because I think the premise is really cool. If I'm on a roll, I'll try #MicroZig too.

    And if I really feel like I have the capacity, I'll port the code to one of these other languages.

    I'm acutely aware of all the other projects I've given myself to do, such as the SIBO SDK and other small Psion-related projects, not to mention $dayjob and $reallife. So we'll see how things go!

    #Pascal #FreePascal #ObjectPascal #RustLang #YargLang #RaspberryPiPico #PiPico #PiPico2 #RP2040 #RP2350

  10. RE: oldbytes.space/@thelastpsion/1

    And the results are in!

    1. Pico C
    2. Rust
    3. Free Pascal
    4. Joint with Pico C++, MicroZig and Yarg.

    So, what am I going to do? Well, I'm leaning towards porting the existing Arduino C code to the Pico C SDK. I'm currently using one class for encapsulation and abstraction, but I could replace that with structs and static functions. I'm not a great C programmer, but I'm pretty comfortable with it, so it makes sense

    However, before I do that, I see a bigger challenge of getting a good setup without using VS Code. I've been using #NeoVim for a while now, and I'd like to get a comfortable setup using that on #Linux.

    So, I'm going to try to build Blinky projects for at least Pico C, Rust and Free Pascal, using Linux and NeoVim. Hopefully this will give me a better feel for how well these languages actually suit me. I've never done any Rust before, either, so that's going to be quite the learning curve!

    If I have time, I'm going to give Yarg a go, too, because I think the premise is really cool. If I'm on a roll, I'll try #MicroZig too.

    And if I really feel like I have the capacity, I'll port the code to one of these other languages.

    I'm acutely aware of all the other projects I've given myself to do, such as the SIBO SDK and other small Psion-related projects, not to mention $dayjob and $reallife. So we'll see how things go!

    #Pascal #FreePascal #ObjectPascal #RustLang #YargLang #RaspberryPiPico #PiPico #PiPico2 #RP2040 #RP2350

  11. vkcube running on 64-bit RISC-V Alpine Linux in my PasRISCV Emulator in turn with the Vulkan-based PasRISCVEmu UI backend. #riscv #vulkan #ObjectPascal #FreePascal #Delphi
    @riscv @vulkan




  12. (1) Does the Apple MacBook Neo support virtualisation (Hypervisor)?

    (2) Can you do macOS/iOS software development on an Apple MacBook Neo?

    (3) Can you do software development on an Apple MacBook Neo?

  13. #Question
    #DearInternet
    #DearFediverse
    #DearLazyWeb

    (1) Does the Apple MacBook Neo support virtualisation (Hypervisor)?

    #HyperVisor #QEMU #VirtualMachine #Virtualisation

    (2) Can you do macOS/iOS software development on an Apple MacBook Neo?

    #Swift #ObjectiveC

    (3) Can you do software development on an Apple MacBook Neo?

    #ObjectPascal #Delphi #Ada #Lisp #Scheme #Racket #SmallTalkLang #SelfLang

    #AppleMacBookNeo #Apple #MacBookNeo

  14. #Question
    #DearInternet
    #DearFediverse
    #DearLazyWeb

    (1) Does the Apple MacBook Neo support virtualisation (Hypervisor)?

    #HyperVisor #QEMU #VirtualMachine #Virtualisation

    (2) Can you do macOS/iOS software development on an Apple MacBook Neo?

    #Swift #ObjectiveC

    (3) Can you do software development on an Apple MacBook Neo?

    #ObjectPascal #Delphi #Ada #Lisp #Scheme #Racket #SmallTalkLang #SelfLang

    #AppleMacBookNeo #Apple #MacBookNeo

  15. #Question
    #DearInternet
    #DearFediverse
    #DearLazyWeb

    (1) Does the Apple MacBook Neo support virtualisation (Hypervisor)?

    #HyperVisor #QEMU #VirtualMachine #Virtualisation

    (2) Can you do macOS/iOS software development on an Apple MacBook Neo?

    #Swift #ObjectiveC

    (3) Can you do software development on an Apple MacBook Neo?

    #ObjectPascal #Delphi #Ada #Lisp #Scheme #Racket #SmallTalkLang #SelfLang

    #AppleMacBookNeo #Apple #MacBookNeo

  16. #Question
    #DearInternet
    #DearFediverse
    #DearLazyWeb

    (1) Does the Apple MacBook Neo support virtualisation (Hypervisor)?

    #HyperVisor #QEMU #VirtualMachine #Virtualisation

    (2) Can you do macOS/iOS software development on an Apple MacBook Neo?

    #Swift #ObjectiveC

    (3) Can you do software development on an Apple MacBook Neo?

    #ObjectPascal #Delphi #Ada #Lisp #Scheme #Racket #SmallTalkLang #SelfLang

    #AppleMacBookNeo #Apple #MacBookNeo

  17. Has anyone managed to get #NeoVim with #DAP and #gdb working with #Pascal?

    I'm using #LazyVim, so a lot of DAP is preconfigured using an Extra (dap.core). Unsurprisingly, Pascal is not one of the languages supported by default.

    #ObjectPascal #FreePascal #debugger

  18. Has anyone managed to get #NeoVim with #DAP and #gdb working with #Pascal?

    I'm using #LazyVim, so a lot of DAP is preconfigured using an Extra (dap.core). Unsurprisingly, Pascal is not one of the languages supported by default.

    #ObjectPascal #FreePascal #debugger

  19. Has anyone managed to get #NeoVim with #DAP and #gdb working with #Pascal?

    I'm using #LazyVim, so a lot of DAP is preconfigured using an Extra (dap.core). Unsurprisingly, Pascal is not one of the languages supported by default.

    #ObjectPascal #FreePascal #debugger

  20. Has anyone managed to get #NeoVim with #DAP and #gdb working with #Pascal?

    I'm using #LazyVim, so a lot of DAP is preconfigured using an Extra (dap.core). Unsurprisingly, Pascal is not one of the languages supported by default.

    #ObjectPascal #FreePascal #debugger

  21. Has anyone managed to get #NeoVim with #DAP and #gdb working with #Pascal?

    I'm using #LazyVim, so a lot of DAP is preconfigured using an Extra (dap.core). Unsurprisingly, Pascal is not one of the languages supported by default.

    #ObjectPascal #FreePascal #debugger

  22. I've been musing on #OOP style. I have a question for the more experienced programmers out there.

    How do you decide when a class's method doesn't actually need to be a method, but instead could just be a regular function?

    I'm not talking about functions that need to be shared between classes. I'm talking about intentionally moving a method outside of a class, even though it will only ever be used by that class.

    For example, if I've got a parser-related function that is only needed by the parser, I will normally just put it in the parser class as a method. It keeps things neat, I can make it private and lock down the class. But I've never before stopped to think whether this is the correct thing to do every time.

    After all, #Pascal (my language of choice) has the concept of units. I could just have some functions just as functions, and only have methods for things that directly need to update the class's properties.

    It would make things easier for testing, too. I wouldn't need to create an instance of a class just to test a specific function works as intended.

    But I don't know if it's the "right" way to do things in OO, or #ObjectPascal for that matter.

    #OO

  23. I've been musing on #OOP style. I have a question for the more experienced programmers out there.

    How do you decide when a class's method doesn't actually need to be a method, but instead could just be a regular function?

    I'm not talking about functions that need to be shared between classes. I'm talking about intentionally moving a method outside of a class, even though it will only ever be used by that class.

    For example, if I've got a parser-related function that is only needed by the parser, I will normally just put it in the parser class as a method. It keeps things neat, I can make it private and lock down the class. But I've never before stopped to think whether this is the correct thing to do every time.

    After all, #Pascal (my language of choice) has the concept of units. I could just have some functions just as functions, and only have methods for things that directly need to update the class's properties.

    It would make things easier for testing, too. I wouldn't need to create an instance of a class just to test a specific function works as intended.

    But I don't know if it's the "right" way to do things in OO, or #ObjectPascal for that matter.

    #OO

  24. If anyone wants to see some incredibly poor #ObjectPascal, here's a link to #ecobj in its current form.

    It's very much at the "work out how any of this works" stage. Expect the code to change radically!

    codeberg.org/thelastpsion/ecobj

  25. If anyone wants to see some incredibly poor #ObjectPascal, here's a link to #ecobj in its current form.

    It's very much at the "work out how any of this works" stage. Expect the code to change radically!

    codeberg.org/thelastpsion/ecobj

  26. If anyone wants to see some incredibly poor #ObjectPascal, here's a link to #ecobj in its current form.

    It's very much at the "work out how any of this works" stage. Expect the code to change radically!

    codeberg.org/thelastpsion/ecobj

  27. If anyone wants to see some incredibly poor #ObjectPascal, here's a link to #ecobj in its current form.

    It's very much at the "work out how any of this works" stage. Expect the code to change radically!

    codeberg.org/thelastpsion/ecobj

  28. If anyone wants to see some incredibly poor #ObjectPascal, here's a link to #ecobj in its current form.

    It's very much at the "work out how any of this works" stage. Expect the code to change radically!

    codeberg.org/thelastpsion/ecobj

  29. PasLLM is finally publicly released!

    A high-performance LLM inference engine written in pure Object Pascal.

    ✨ No Python dependencies
    🎯 Advanced 4-bit quantization
    🖥️ Cross-platform (Delphi & FreePascal)
    ⚡ Native performance

    Supports Llama 3.x, Qwen, Phi-3, Mixtral, DeepSeek R1 & more!

    Open source (AGPL 3.0): github.com/BeRo1985/pasllm (synced from my private repo on my on server)

    #ObjectPascal #Delphi #FreePascal #LLM #AI

  30. If you were writing a #compiler (or, in my case, a #preprocessor) and you had to think of a variable name for a "class" struct, but you can't use the keyword class... what would you call that variable?

    Plot twist: The compiler/preprocessor is written in #ObjectPascal. (So it's actually a record, not a struct. Same difference.)

    I'm currently using the variable name class_item which is a very un-Pascal identifier for many reasons. I'm thinking of using PClass or PsiClass just to get around it.

    #Pascal #FreePascal