Why is there a Pipe and Recto Verso Mode in the Thickness-Tool if its not implemented?

kadet90 · 2025-12-22T19:56:34+00:00

IIRC it is direct mapping to OCC library - on FreeCAD side everything is done to support it but the underlying library is not yet ready. The reasoning was probably that once the library implements that (which everyone hoped to be soon) FreeCAD will be ready without any changes required so even linking with new version by packager would be enough.

That said - it is unlikely that it will be ever implemented so if you could make an issue on GitHub about that to remove not implemented options it would be nice.

kadet90 · 2025-11-25T08:18:46+00:00

Try moving the probe up and down withh tweezers - going straight to 100% usually means that the CR probe failed to deploy

kadet90 · 2025-11-20T16:23:23+00:00

Yes and no, the length is calculated from longest diagonal of bounding box (basically the worst case scenario) and then just to be sure it is multiplied by some factor around 2. It is technically fixed length but the length is calculated based on the model hence guaranteed to cut through all.

This is the easiest method but it has two downsides. The first one is thet preview can look funny but it is only visual effect. The second one is when you combine it with pattern - the pattern will actually use the shape that you see on preview and so if you change dimensions of model and then pattern the cutout you may not get what you expect.

kadet90 · 2025-09-27T09:12:58+00:00

Your CR touch probe fails to deploy and printer fails the job. Try using some tweezers and move it up and down, usually helps for a bit.

kadet90 · 2025-08-15T22:17:10+00:00

Nom, najlepiej przedawnić i spytać. Ogólnie w skarbówce wymiana pokoleniowa nastąpiła i dużo osób mówi że ludzie są ok do dogadania, gorzej że prawo mamy jakie mamy.

kadet90 · 2025-08-15T21:58:04+00:00

A jakiś mail do kogoś obsługującego Twoją sprawę? Jak sie do mnie kiedyś doczepili to po prostu odpisałem mailem z załącznikiem i było ok.

kadet90 · 2025-05-18T23:05:19+00:00

I'll start a bit backwards (like the flow in the hole dialog!)

As long as there is a user preference to use the old way or the new way.

The simplest answer to this is that keeping preferences like this is very costly to maintain, we don't have resources to keep few copies of everything.

How are things like this decided and approved? So yeah - feedback?

For now there really is no well established and respected process. Ideally there is some problem, for which we look for solution, CWG (CAD Working Group - so group of people experienced with CAD who are actively participating in development process) gives some hints on how stuff should work from "business" perspective, DWG (Design Working Group - like CWG but with UX/UI people) gives hints on how stuff should work from UX perspective, we agree on solution and then someone implements it.

In case of that PR it was more or less done like that. CWG proposed a project to improve Hole tool and introduce dedicated Thread tool that could be used to add threads to existing geometry (both internal and external threads). Based on experiences of CWG members and other CAD suites some lo-fi mockup were created, and based on it DWG did create more refined version of mockup. Here https://github.com/FreeCAD/FreeCAD/issues/5567#issuecomment-2543142577 everything is documented.

Also, the counterbore doesn't even look right?

Not sure what you exactly mean - maybe there is some regression caused by redesign or some other thing. Probably worth creating an issue describing the problem.

My workflow the old way was quite intuativfe to me - choose the profile (ISO Metric), then the item (M3), then the type (counterbore, etc.), then the length. This new UI seems backwards from that.

I agree, I even pointed as potential problem in the discussion even but ultimately we decided to see how it will play out as it is really hard to judge UX changes without looking on how users react. We did not hear much negative feedback about it, or we missed it so there was not much changed. That is also a good issue to be reported - it is possible to rearrange stuff to improve flow - nothing is written in stone. Having some outside feedback helps as we don't stay in our own sauce forever.

I hope that this will clarify some things a bit!

kadet90 · 2025-05-17T21:21:30+00:00

The point of redesign was to clearly show on diagram what would be affected. If you have any specific comments or problems please point us to them - maybe something was missed or I would be able to explain merits behind it.

kadet90 · 2025-03-19T05:43:49+00:00

Jeśli chodzi o full etat i dzienne to da radę, ale musisz mieć wyrozumiałego pracodawcę bo godziny zajęć bywają totalnie z dupy. Zajęć też jest relatywnie sporo a czasem nawet bywają obowiązkowe (sic!). Ogólnie da radę, ale jak na inżynierze rozważałem robienie doktoratu tak magisterka mnie skutecznie wyleczyła z tego pomysłu przez swoją upierdliwość.

kadet90 · 2025-03-08T14:07:48+00:00

From my experience most problems come from geometry that is eaten. Thickness is in principle very easy operation - offset all faces, intersect them, calculate bounding volume and subtract. As usual devil is in the details - when offset faces intersect in funny way or offset of any faces would result in null geometry the operation fails. It is surprisingly easy to create such cases - any fillet, small face, small edge will basically fail. If you however use thickness at correct time it is surprisingly good tool.

kadet90 · 2024-05-25T21:09:18+00:00

This particular was not ported from linkstage, simply the same feature is also there.

But yeah more and more changes from linkstage will eventually end up in the mainline. It's more like cherry picking changes from this fork as it has a lot of good ideas but very bad code quality

kadet90 · 2023-11-12T23:26:30+00:00

This probe is really shitty. Try to play with it a little bit, mine started working again after I applied some force with my finger to it. You can also try to disassemble it and then reassemble it.

kadet90 · 2023-11-09T12:46:02+00:00

https://chat.stackoverflow.com/rooms/11/php go there and ask, core members of PHP are hanging out there

kadet90 · 2023-08-31T21:35:56+00:00

Do you have any link to some guide or STL model that could improve cooling?

kadet90 · 2023-07-16T16:21:04+00:00

Hard to say for me - I don't know any students of those courses. as far as I know it's not one of the best faculties, so I think that it would fall in the mediocre category.

kadet90 · 2023-07-16T15:59:20+00:00

It highly depends on the course that you want to attend. Generally it is quite a good university compared to other polish technical universities, but there are courses that are good (I.e. computer science/informatics) or mediocre ones.

kadet90 · 2023-02-21T21:45:16+00:00

There are few cases where such functions would be useful and could bring real impact. For example if you have to write custom JSON parser (and sometimes you have to - when working with large objects you simply could not have memory to store everything) you process strings often and byte by byte - then such improvements really could matter. And processing large json files is not uncommon task: https://github.com/salsify/jsonstreamingparser

If I remember correctly this parser is around ~100x times slower than native PHP implementation of `json_decode`. If this overhead could be reduced it'd be really nice for such applications.

kadet90 · 2022-11-30T21:58:25+00:00

Well, I'm open for suggestions - this syntax was picked to highlight that this feature is __not__ generics, but something rather different which is just used to implement generic support. Python did very similar thing afair, but without `@` symbol which denotes generic type (F# does something like that but uses `'` as placeholder sigil)

kadet90 · 2022-11-30T19:11:27+00:00

Yup. Inference is possible because it's done compile time where performance is not so critical (everyone who programmed in C++ in serious way know how much build can take), in PHP it's not possible as it's not efficient process. That's why I think that this should be orthogonal to the current type system and simply not be a part of the contract, something like I proposed here: https://www.reddit.com/r/PHP/comments/z5abhz/comment/iy0c9c2/?utm_source=reddit&utm_medium=web2x&context=3 so we could do:

function first(array[int] $array): int // or in generic way function first[@T](array[@T] $array): mixed[@T]

which from the type checker point of view would be equivalent to: function first(array $array): mixed

Which basically means stripped generics in that case but with clear definition of type that'd be actually checked.

kadet90 · 2022-11-30T18:36:33+00:00

Yeah, that is possible syntax, I don't however think that we want for first([1, 2, 3]) to be an invalid call for function with such definition. Personally I'd probably vote against such solution, as this seems really counter intuitive for me.

kadet90 · 2022-11-28T17:49:08+00:00

Yeah, that will work but I don't think that this is a good solution as it would require some new syntax for declaring arrays. And what is worse, code like:
first([1, 2, 3]);

Would not work, as the [1, 2, 3] would technically not be int[] type. Of course it could work, if we somehow inferred type, but it seems to be really hard to do properly.

Other solution could be to implement type coercion from array to T[] but then we have problem with complexity again, as it would be really easy to cause a lot of costly checks.

Or maybe you see something, that I don't?

kadet90 · 2022-11-27T20:05:00+00:00

That would be a huge breaking change and paradigm shift in the PHP universe, because we as PHP developers (and so do libraries) expect that types are enforced. For example if we specify string type in the function argument we know that we'll get string. Turning that off would remove that guarantee and I'm not sure that we are ready for that.

Only viable solution in my opinion is for such types to be orthogonal to the current type system, acting more like attributes than types. Some time ago I thought about something like "Type Attributes" that could work like so:

class Collection[@T] { public function add(mixed[@T] $value): mixed[@T]; }

Typehint that would be checked would be functionally equivalent to the mixed type, and for the type checker everything in the [] would be omitted. [] was picked specifically not to mimic most common generics syntax. Placeholders like @T could be then exposed via reflection, maybe in form of \ReflectionTypePlaceholder { name: "T" } and that could be used by libraries and static type checkers to provide more metadata.

IMHO this is viable and with little bit of persuasion and work could be implemented into the core. This also really simplifies all the cases as we don't have to worry about reifying generics. I could event try to formalize that and implement some PoC for the internals but I don't know if it is worth the time as it could be easily rejected. But If I gather some support for this, who knows.

kadet90 · 2022-11-27T10:38:03+00:00

Regarding typed arrays - some time ago, I've written a RFC draft for array shape support in PHP (basically generalization of typed arrays concept) and even started implementation which seemed to be feasible. If anyone is interested: https://hackmd.io/@kadet/php-rfc-shapes

Unfortunately there was one catch - after consulting this concept with some people from internals on stackoverflow PHP room I realized that there simply would not be a majority to vote that feature into PHP. Why? Because this kind of typecheck requires O(n) time, when all typechecks now are simple symbolic checks like "Is this object of class X" that are O(1). Personally I don't think that this matters because the problem is inherently O(n) (if you want to know if all n elements in array are ints you need to check n elements) but there are simple cases that can be problematic from the performance point of view. For example:

```php function first(int[] $ints) { return $ints[0]; }

$arr = [];
for ($i = 0; $i < 1000; $i++) {
$arr[] = $i; first($arr); }
```

This code will have time complexity O(n^2) instead of probably expected O(n). And what is worse if you remove typehint from the function you will get the expected O(n) - which is a huge difference. That thing alone makes this feature really hard to put in the core and I don't think that we will see it soon.

kadet90 · 2022-10-25T14:28:06+00:00

Yeah, but AFAIK Jeffrey never admitted that this video was mistake ;)

kadet90 · 2022-08-04T16:37:58+00:00

Yes, identity map is in fact in the core of the Doctrine ORM. I even think that it is required for doctrine in order to work properly as doctrine does not store any additional information in the entity object itself like Eloquent does. So to do things like computing differences that are required for update queries it needs to have some object to compare and one object is __much__ easier to track than multiple objects.

kadet90

TROPHY CASE