profile
viewpoint
Rick van Hattem WoLpH Amsterdam http://wol.ph/ Author of @mastering-python and entrepreneur interested in scaling large and complicated systems.

WoLpH/alfred-converter 45

Alfred unit converter is a smart calculator for Alfred with support for unit conversions to make it a bit comparable to the Google Calculator and Wolfram Alpha.

WoLpH/Cache-Debug-Toolbar 13

Django Cache Debug Toolbar for Redis, Memcache and PyLibMC

ShinNoNoir/bson_lazy 4

Lazy loading of BSON files and bson2json.py utility

WoLpH/coffin 2

Jinja2 adapter for Django

RickDB/newznab-tmux-theme-omega 1

Omega theme for Newznab-Tmux

tschellenbach/Skipper 1

Deploy webinterface

WoLpH/atmoorb-photon 1

AtmoOrb Particle Photon code

WoLpH/celery 1

Distributed Task Queue (development branch)

jorenham/selenium-wire 0

Extends Selenium's Python bindings to give you the ability to inspect requests made by the browser.

startedlmammino/node-js-race-conditions

started time in 14 hours

startedAmanieu/parking_lot

started time in 15 hours

startedDirtyHairy/async-mutex

started time in 2 days

issue commentWoLpH/numpy-stl

ASCII/binary detection issues

Thanks. I will see if I manage to make a PR next week.

hakostra

comment created time in 2 days

Pull request review commentWoLpH/numpy-stl

Support writing to io.BytesIO() psuedo files.

 def save(self, filename, fh=None, mode=AUTOMATIC, update_normals=True):             self.update_normals()          if mode is AUTOMATIC:-            if fh and os.isatty(fh.fileno()):  # pragma: no cover-                write = self._write_ascii-            else:-                write = self._write_binary+            # Try to determine if the file is a TTY. If it fails then it's+            # a io.BytesIO() (or something similar) - default to BINARY in this+            # case.+            write = self._write_binary+            if fh:  # pragma: no cover+                try:+                    if os.isatty(fh.fileno()):+                        write = self._write_ascii+                except IOError:+                    pass

It will silently ignore that os.isatty(fh.fileno()) failed. But write will still be set because of the

             write = self._write_binary 

line above it. No writing actually happens until further down either way.

I think I'll restructure that. It took me a bit of staring to work out that I hadn't forgotten to set write for either isatty() returns false or it fails.

bwoodsend

comment created time in 2 days

pull request commentWoLpH/python-utils

Install only python_utils as package

In case you are using vim: I can recommend creating a snippet for ultisnips for this use-case! :)

Glad it's solved!

dvzrv

comment created time in 2 days

issue closedWoLpH/python-utils

2.5.0: Installs tests into top-level directory

Hi! I package python-utils for Arch Linux.

When packaging 2.5.0, I noticed, that now the tests are installed top-level into the site-packages directory. This is a problem, because it will conflict with other packages (it happens from time to time, that packages accidentally install tests globally).

To fix this, the packages parameter for setuptools' setup() needs to be specified in such a way, that it only installs the contents of the utils, but not that of the tests.

closed time in 2 days

dvzrv

created repositorylmammino/node-js-race-conditions

A series of examples illustrating race conditions in Node.js and potential solutions

created time in 2 days

pull request commentWoLpH/python-utils

Install only python_utils as package

Codecov Report

Merging #12 (632a90d) into develop (f65dd4b) will not change coverage. The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##           develop       #12   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          202       202           
  Branches        45        45           
=========================================
  Hits           202       202           

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f65dd4b...632a90d. Read the comment docs.

dvzrv

comment created time in 2 days

pull request commentWoLpH/python-utils

Install only python_utils as package

Coverage Status

Coverage remained the same at 100.0% when pulling 632a90dfbf9195cb67ea9e8c7248b31ecf88af6d on dvzrv:issues/11 into f65dd4b86c8fb7575e8b52855139d883baffcd89 on WoLpH:develop.

dvzrv

comment created time in 2 days

pull request commentWoLpH/python-utils

Install only python_utils as package

Coverage Status

Coverage remained the same at 100.0% when pulling 632a90dfbf9195cb67ea9e8c7248b31ecf88af6d on dvzrv:issues/11 into f65dd4b86c8fb7575e8b52855139d883baffcd89 on WoLpH:develop.

dvzrv

comment created time in 2 days

pull request commentWoLpH/python-utils

Install only python_utils as package

Guess you can now decide whether you would like your glass "half full" or "half empty" :laughing:

dvzrv

comment created time in 2 days

pull request commentWoLpH/python-utils

Install only python_utils as package

Ah lol, just realized that this is a dup implementation of #10

dvzrv

comment created time in 2 days

PR opened WoLpH/python-utils

Install only python_utils as package

setup.py: Provide an include list for setuptools.find_packages() [1], which is called within setuptools.setup()'s packages parameter. This prevents the tests being picked up as a package and installed top-level in the site-packages directory (conflicting with other packages, that also make this mistake).

Fixes #11

[1] https://packaging.python.org/guides/distributing-packages-using-setuptools/#packages

+1 -1

0 comment

1 changed file

pr created time in 2 days

fork dvzrv/python-utils

Python Utils is a module with some convenient utilities not included with the standard Python install

http://python-utils.readthedocs.io/en/latest/

fork in 2 days

issue openedWoLpH/python-utils

2.5.0: Installs tests into top-level directory

Hi! I package python-utils for Arch Linux.

When packaging 2.5.0, I noticed, that now the tests are installed top-level into the site-packages directory. This is a problem, because it will conflict with other packages (it happens from time to time, that packages accidentally install tests globally).

To fix this, the packages parameter for setuptools' setup() needs to be specified in such a way, that it only installs the contents of the utils, but not that of the tests.

created time in 2 days

pull request commentWoLpH/python-utils

do not install a global 'tests' package

Codecov Report

Merging #10 (d433290) into develop (f65dd4b) will not change coverage. The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##           develop       #10   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          202       202           
  Branches        45        45           
=========================================
  Hits           202       202           

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f65dd4b...d433290. Read the comment docs.

mgorny

comment created time in 2 days

pull request commentWoLpH/python-utils

do not install a global 'tests' package

Coverage Status

Coverage remained the same at 100.0% when pulling d433290bfb9583619448ca94195fa607412807d7 on mgorny:setup.py-tests into f65dd4b86c8fb7575e8b52855139d883baffcd89 on WoLpH:develop.

mgorny

comment created time in 2 days

PR opened WoLpH/python-utils

do not install a global 'tests' package

setuptools.find_packages() finds all valid packages by default that incidentally includes the test directory that gets installed as global 'tests'. Add an explicit exclude to avoid that.

+1 -1

0 comment

1 changed file

pr created time in 2 days

fork mgorny/python-utils

Python Utils is a module with some convenient utilities not included with the standard Python install

http://python-utils.readthedocs.io/en/latest/

fork in 2 days

issue openedWoLpH/numpy-stl

ASCII/binary detection issues

I just came across some STL files generated by the computational fluid dynamics software Star-CCM+, where numpy-stl fail to load the ASCII STL's.

This old bug in OpenFOAM have two simple examples attached: https://bugs.openfoam.org/view.php?id=516 see the file "cubes.zip". I attach the same file here as a reference: cubes.zip

The ASCII STL's start with " solid", i.e. a whitespace before the word "solid". This puzzles the automatic ASCII/binary detection in numpy-stl and it is attempted to read the file as binary, which fails.

The best descriptions I have found for the STL file format(s) are Wikipedia [1] and a page on fabbers.com [2]. Neither of them are perfectly clear on the validity of this file(s) coming from Star-CCM+... These resources (Wikipedia, Fabbers) are also sometimes in conflict, Wikipedia list tabs as examples of allowed whitespace characters and Fabbers explicitly write that this is not allowed. Fabbers, being an old resource, write that all coordinates must be non-negative, which is rarely enforced today. Wikipedia write that the file must start with the line "solid name", but later they state that whitespace may be used anywhere in the file except within numbers or words...

I then in the end conclude that whitespace are also allowed before the first "solid", and that both of the STL's in the attached file are valid STL's (even though both are really stupid in their own ways).

First I would like to know your thoughts on the validity of the attached STL's.

Then, secondly I do not like the current method of reading ASCII/binary STL's. I can force the reading of a binary STL with mode=Mode.BINARY, but the same is not true for Mode.ASCII, since by code design in stl.py:70 it nevertheless will jump to binary reading, since the first five characters of the file is not "solid"...

What would be the opinions on really having three modes: ASCII, binary and automatic? In ASCII mode it would never fall back to binary, in binary mode it would never fall back to ASCII and in automatic it would make an educated guess on the mode based on the file structure, and possibly fall back to the other mode if the first is failing. Opinions?

It can be possible for me to provide some pull request solving some of this, but I would like to hear your opinion first.

[1] https://en.wikipedia.org/wiki/STL_(file_format) [2] http://www.fabbers.com/tech/STL_Format

created time in 2 days

fork hakostra/numpy-stl

Simple library to make working with STL files (and 3D objects in general) fast and easy.

http://numpy-stl.readthedocs.org/

fork in 2 days

startedatlassian/changesets

started time in 3 days

fork sinkdwty/redis-py

Redis Python Client

fork in 3 days

issue commentTribler/distributed-ai-kernel

Decentralized peer to peer

X-mas vacation, spent 12h on honor project. Cleaning of code. Superapp is going strong: <img src="https://user-images.githubusercontent.com/4957928/103173843-e5d48280-485d-11eb-907a-e20c9b25fbba.gif" width=200/>

JayDew

comment created time in 3 days

startedjwise/snow

started time in 3 days

startedWoLpH/numpy-stl

started time in 3 days

issue openedWoLpH/numpy-stl

Valid stl file (case sensitivity)

Is the file HalfDonut.stl a valid stl file? solid HalfDonut.stl ... ENDSOLID HalfDonut.stl

An ASCII STL file begins with the line

sold <name>

The file concludes with endsolid <name>

What about case sensitivity of endsolid?

https://en.wikipedia.org/wiki/STL_(file_format)

created time in 4 days

fork LeslieZhu/fftw3

DO NOT CHECK OUT THESE FILES FROM GITHUB UNLESS YOU KNOW WHAT YOU ARE DOING. (See below.)

fork in 4 days

fork LeslieZhu/redis-plus-plus

Redis client written in C++

fork in 4 days

more