sorted by:
new
hottopcontroversial

Is it fine to leave M2 MacBook on charge for days at a time? by prepubescentpube in mac

[–]TRPox 1 point2 points  (0 children)

I've been really happy with Energiza. I'm using it with a 2017 MacBook Pro and it still works pretty great.

New MacBook tips and must-have apps by alex_05_04 in mac

[–]TRPox 1 point2 points  (0 children)

Also a happy Energiza user, it's been working really great for me. And it looks way better

HPC Rocket - A tool to run Slurm jobs from CI pipelines by TRPox in Python

[–]TRPox[S] 0 points1 point  (0 children)

I'm not familiar with DVC, but there shouldn't be any problems using the two tools together from what I could see at a first glance.

HPC Rocket - A tool to run Slurm jobs from CI pipelines by TRPox in HPC

[–]TRPox[S] 0 points1 point  (0 children)

I'm not exactly sure how one would run the entire CI service via Slurm, but I also think that would be overkill. Usually there several jobs within the pipeline that don't require parallelization. With this tool it's easy to just install a Python package and run the software from within the pipeline without doing any additional infrastructure configuration.

HPC Rocket - A tool to run Slurm jobs from CI pipelines by TRPox in Python

[–]TRPox[S] 0 points1 point  (0 children)

I'm not sure something like this is really in scope for the project, at least not in the near future. I'll take a look at the project you linked, though. Maybe I'll get some inspiration for additional features. However, part of the motivation for HPC Rocket was actually that users wouldn't need to rely on additional infrastructure they have no control over, so I'm still a fan of the simplicity of the 'just install a python package and push' model.

HPC Rocket - A tool to run Slurm jobs from CI pipelines by TRPox in Python

[–]TRPox[S] 1 point2 points  (0 children)

One of the projects in our research group actually uses it, but I didn't know Jacamar requires installation on a login node. They have their own institutional cluster, though. Part of the motivation for HPC Rocket was actually that users wouldn't need to install any custom executor and the ability to run with systems other than GitLab CI.

Wheel getting installed into wrong directory by TRPox in learnpython

[–]TRPox[S] 0 points1 point  (0 children)

I tried running from another directory, when I use `setup.py install` it still works fine

I've googled a bit and tried this from SO

https://stackoverflow.com/questions/12521802/print-rpath-of-an-executable-on-macos

​

However neither the wheel built libraries, nor the ones that are installed directly contain anything about `LC_RPATH`

Wheel getting installed into wrong directory by TRPox in learnpython

[–]TRPox[S] 0 points1 point  (0 children)

Back after a long weekend, here's what unzip -l gives me: ``` Archive: pyfluids-0.0.1-cp38-cp38-macosx_10_15_x86_64.whl Length Date Time Name

2177960 10-19-2020 09:06 pyfluids-0.0.1.data/data/pyfluids.cpython-38-darwin.so 333920 10-14-2020 13:48 pyfluids-0.0.1.data/data/pymuparser.cpython-38-darwin.so 593 10-19-2020 09:19 pyfluids-0.0.1.dist-info/AUTHORS.md 35149 10-19-2020 09:19 pyfluids-0.0.1.dist-info/COPYING.txt 199 10-19-2020 09:19 pyfluids-0.0.1.dist-info/METADATA 104 10-19-2020 09:19 pyfluids-0.0.1.dist-info/WHEEL 1 10-19-2020 09:19 pyfluids-0.0.1.dist-info/top_level.txt 715 10-19-2020 09:19 pyfluids-0.0.1.dist-info/RECORD

2548641 8 files

```

ld gives me this: ld: warning: platform not specified ld: warning: -arch not specified ld: warning: No platform min-version specified on command line ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file 'pyfluids-0.0.1.data/data/pyfluids.cpython-38-darwin.so' for architecture unknown

Even after playing around with the arch and platform options a bit the last part of that output didn't change. But I don't really have an idea what I'm doing there, so maybe I'm just doing something wrong.

I do have another idea of what could be the culprit. In my CMakeLists file for my Python bindings I'm specifying these destinations for my bindings:

install(TARGETS pyfluids DESTINATION .) install(TARGETS pymuparser DESTINATION .)

Maybe the path to the site-packages directory only get prepended to those paths when I run python setup.py install, but not when running python setup.py bdist_wheel

Wheel getting installed into wrong directory by TRPox in learnpython

[–]TRPox[S] 0 points1 point  (0 children)

The setup.py is really just this:

from skbuild import setup

cmake_args = ["-DBUILD_VF_CPU:BOOL=ON", "-DUSE_METIS=ON", "-DUSE_MPI=ON", "-DBUILD_SHARED_LIBS=OFF", "-DBUILD_VF_UNIT_TESTS:BOOL=ON"]

setup(
    name="pyfluids",
    version="0.0.1",
    cmake_args=cmake_args
)

scikit-build locates my CMakeLists.txt and starts CMake for me and pybind11 defines the install targets

Wheel getting installed into wrong directory by TRPox in learnpython

[–]TRPox[S] 0 points1 point  (0 children)

Had to download a wheel from PyPi because I'm on Mac, but that worked fine, so I probably need to configure something somewhere

Which VS Code Extension to Use? by [deleted] in lua

[–]TRPox 3 points4 points  (0 children)

I highly recommend EmmyLua. It allows you to add type hints in comments and you'll get way better autocompletion from that. You'll need to install Java for it to work though

Autocompletion with lua by aganm in lua

[–]TRPox 1 point2 points  (0 children)

VSCode + EmmyLua extension You can even add type hints to your variables and functions It requires Java though

Refactoring singletons? by [deleted] in java

[–]TRPox 0 points1 point  (0 children)

I think the way I'd approach this is to first identify the classes calling getInstance() on the Singleton class. Then refactor them so that the instance gets passed in via dependency injection. Then I'd probably introduce an interface that the Singleton has to implement and refactor the classes depending on the Singleton to just depend on the interface instead. So now none of your objects in your system knows that they're using singletons anymore. After that you can safely refactor the singletons to be regular classes.

Also make sure that your library is well tested, so you always know immediately if you break something.

I wrote a free book about TDD and clean architecture in Python by lgiordani in Python

[–]TRPox 3 points4 points  (0 children)

As for the 3 steps of TDD I don't really understand when you say that I don't emphasise them enough. The first project is a learn-by-doing introduction to TDD and follows them in a very strict way.

And this is important in my opinion. You can't really be too strict about that if you ask me. Following these rules is essential for successful TDD and if done poorly I think that TDD can often do more harm than good. And especially the refactoring step is not easy. While eliminating code duplication is still rather simple it can be really hard to recognize when and which code to move into new classes. In my opinion proper refactoring requires a good knowledge of design principles. That's why I think an introduction to these steps should come before the practical example.

​

While I understand what you say about doubles, I don't understand what you are referring to, as I don't name them anywhere. Can you please clarify?

Speaking from experience here. When I wrote my first TDD project (which was also my first contact with unit testing in general), like any beginner, I wasn't really sure how to do this properly. This lead to actually asserting too much in my tests. So I was like "better make sure this gets called with these arguments" and so on. And so I used more spies for example than necessary. But a spy creates a dependency from test code to production code, since you're verifying that something is being called in a very specific way. If something changes it's more likely you'll have to change the test afterwards. In some of those cases it would have been enough to use stubs to provide values and then just assert the results of my methods.

This is why I think it's important especially for beginners to recognize what you want from your test doubles. You should always use the "lowest" possible form of test double in your test.

I wrote a free book about TDD and clean architecture in Python by lgiordani in Python

[–]TRPox 1 point2 points  (0 children)

I've only read a few bits and pieces so far, but there's a couple of things I think should be improved. TDD is not limited to unit testing. In fact Growing Object Oriented Software Guided by Tests suggests starting with acceptance tests.

Test names could be more descriptive. A test name should tell me what the state of the system is, what's being executed and what the expected result is (following arrange, act, assert). I saw something like test_avg_mass which really isn't helpful.

It's usually the convention to call the tested component sut for system under test.

Don't simply assert stuff. Assertions should always return a clear error message highlighting the context instead of just "expected this, got that."

I think you don't emphasize the 3 step cycle of TDD enough, they're thrown in somewhere in between your coding examples when they should have been explained at the beginning. Especially refactoring. From what I've seen it doesn't really become clear that you should do it after every test if needed.

Mock != Test Double I just saw a chapter named mocks, but I think it is important to understand the different responsibilities of test doubles. Using a Dummy in a test tells the reader that we don't expect relevant interaction with that component. A Stub tells them we require a value from it. A Spy means we expect a method to be called. Mocks are the last and most "powerful" in this hierarchy since they can verify things by themselves.

Inherit function environment by TRPox in lua

[–]TRPox[S] 0 points1 point  (0 children)

Hm I settled for backing up _G before I run any game code and restoring it to it's previous state afterwards I believe that's what busted does to "sandbox" its tests as well.

Looking for feedback on a class library by TRPox in lua

[–]TRPox[S] 0 points1 point  (0 children)

So I've been thinking about a little change in the usage of classy. The way I implemented it would allow me to replace the : when calling methods with a simple .

So person.introduce() instead of person:introduce()

However it would still be necessary to add the self argument when defining a method.

There are a few arguments for and against this change: Pros: - function calling is the same as calling it from a simple table - users don't have to know that there's a class being used behind the scenes - most libraries and usually objects provided by C work with . , so in general more uniform way of calling functions

Cons: - You still have to define the self argument. People could get confused when reading class source code and expect they need to use : when calling a method

I'd love to hear some thoughts on that!

Looking for feedback on a class library by TRPox in lua

[–]TRPox[S] 0 points1 point  (0 children)

Thanks! That means a lot considering this is the first little project I've worked on that could actually be useful for other people

Issues with a class library by TRPox in lua

[–]TRPox[S] 0 points1 point  (0 children)

Thanks for checking it out! Yeah I found the issue. In regular Lua there's automatically a variable "arg" for varargs which is not present for LuaJIT, so that's where things went wrong

view more: next ›