00:00 reportable6 left 00:02 reportable6 joined 00:09 stanrifkin joined
stanrifkin Is something wrong with the Physics::Measure module? termbin.com/lusb 00:10
.WHAT fails with "Cannot look up attributes in a Physics::Measure::Power type object. Did you forget a '.new'?"
00:21 jmcgnh left
antononcube @stanrfkin This error might occur because some special gist form has been defined in that package. 00:30
Well, I should experimented prior to voicing an opinion… 00:32
stanrifkin I wonder because the tests didn't fail while installing 00:33
and it tests .WHAT against some strings
00:34 jpn joined, jmcgnh joined
antononcube I browsed the code of “Physics::Measure” — it is the .gist method IMO. It has to defend as: multi method gist(::?CLASS:D:-->Str) , not just gist . 00:39
00:39 jpn left
stanrifkin antononcube: OK. What can I do? 00:45
antononcube Submit an issue. What happens if you just use .raku ? 00:54
01:06 kylese left, kylese joined 01:35 jpn joined
stanrifkin Physics::Measure::Power.new(value => 24, units => Unit.new( factor => 1, offset => 0, defn => 'watt', type => Power, 01:40
dims => [2,1,-3,0,0,0,0,0], dmix => ("W"=>1).MixHash, names => ['W','watt','watts'] );
, error => Error)
antononcube: wasn't expecting that output
01:40 jpn left
stanrifkin antononcube: so it's worth an issue. OK 01:40
02:03 rir_ left
antononcube 👍 02:07
02:15 kylese left, kylese joined 02:36 jpn joined 02:40 jpn left 03:37 jpn joined 03:40 stanrifkin_ joined 03:42 jpn left 03:43 stanrifkin left 04:38 jpn joined 04:43 jpn left 05:39 jpn joined 05:44 jpn left 05:54 holyghost joined
holyghost Hi, I've just updated EyeofTheBeholder to v0.1.8, there's now a get/set for the main D&D stats 05:55
tellable6 2024-04-15T10:42:20Z #raku <tbrowder> holyghost: can't easily find yr module through raku.land.
holyghost tell tbrowder how do I do that 05:57
+tell tbrowder how do I do that
I don't know raku.land, I'll see him later on 05:58
06:00 reportable6 left 06:01 reportable6 joined
holyghost Anyway, it's a nouveau netback system, though a very simple 06:05
You can drain experience points for example
Just my 2 cents
I might want to do a Icewind Dale with it, although not graphical 06:06
As the DnD Rime of the Frostmaiden booklet 06:07
*D&D
06:40 jpn joined
holyghost tbrowder, I only uploaded v0.1.3 a`and now v0.1.8 to CPAN in a Perl6 directory, HTH 06:41
*and
06:45 jpn left 07:41 jpn joined 07:46 jpn left 07:57 jpn joined 08:04 jpn left 08:06 jpn joined 08:11 jpn left 08:36 jpn joined 09:22 jpn left 09:29 holyghost left 09:48 Sgeo left 10:30 jpn joined 11:02 jpn left 11:28 abraxxa-home joined 12:00 reportable6 left 12:03 reportable6 joined 13:49 simcop2387 left, perlbot left 14:20 jpn joined 14:23 simcop2387 joined 14:25 perlbot joined 14:26 jpn left 15:10 abraxxa-home left
librasteve stanrifkin: thanks for trying the Physics::Measure module ... I have reproduced the the error from say $po.WHAT; ... the best way to get the type is say $po.^name;, please let me know if that works for you 15:14
tellable6 librasteve, I'll pass your message to stanrifkin
librasteve you are getting the expected output from $po.raku: 15:15
Physics::Measure::Power.new(value => 24, units => Unit.new( factor => 1, offset => 0, defn => 'watt', type => Power, dims => [2,1,-3,0,0,0,0,0], dmix => ("W"=>1).MixHash, names => ['W','watt','watts'] ); , error => Error)
$obj.^name works as expected ... with the same output as $obj.raku 15:20
generally, I have seen that $obj.^name is now preferred over $obj.WHAT ... I would welcome advice over whether I need to provide a .WHAT method manually but I suspect that would conflict with the usual MOP mechanism. maybe someone can let me know if / how I can help to get $obj.WHAT to work as expected?
(PS. I am the module author) 15:23
stanrifkin_ $obj.raku is not the same as $obj.^name here. $obj.^name outputs just "Physics::Measure::Power". The example code uses $obj.WHAT. github.com/librasteve/raku-Physics-Measure and the some of the test code. Here for example github.com/librasteve/raku-Physics....rakutest. So I was confused why my call didn't work. 15:41
tellable6 2024-05-05T15:14:38Z #raku <librasteve> stanrifkin: thanks for trying the Physics::Measure module ... I have reproduced the the error from say $po.WHAT; ... the best way to get the type is say $po.^name;, please let me know if that works for you
15:41 sena_kun joined
stanrifkin_ librasteve ^ 15:41
But $obj.^name seems to work. So it's fine by now. 15:42
15:43 jpn joined
Voldenet librasteve: docs.raku.org/language/mop#WHAT 15:48
15:48 jpn left
Voldenet since it's ignored, I'm guessing the only correct way of doing this is composing class using metamodel 15:48
which is what it is 15:50
15:56 Altai-man joined 15:58 sena_kun left
Voldenet m: class Unit { has $.name; }; class Measure { has Unit $.u; has Int $.v; }; constant Watt := Metamodel::ClassHOW.new_type(name => "Watt"); Watt.^add_parent(Unit); Watt.^compose; say Measure.new(:u(Watt), :v(42)).u 15:59
camelia (Watt)
Voldenet i'm not entirely sure if I grasp the problem though 16:00
stanrifkin_ Voldenet: not sure what you're doing. Did it work for you? 16:02
Voldenet: Here was the simple example I made. termbin.com/lpba 16:03
Voldenet Well, I'm suggesting a bit of a change in structure of Physics::Unit::CreateUnit by wrapping created types into newly created types inheriting from Unit 16:06
I'm not sure how much of a change would it be to the library 16:07
since Unit allows users to define new types 16:08
though .WHAT would work as expected
erm, Physics::Unit.CreateUnit 16:09
librasteve Voldenet: that makes sense, I am currently working on a refactor / v2 of these modules and will try to do this via MOP - for the record, Physics::Unit always returns a Unit object. Physics::Measure will assemble value, unit and error into a predefined subtype - Physics::Measure::Power, Physics::Measure::Length and so on - so that's where the magic will need to be done. That way raku type system prevents you from 16:38
adding a Power to a Length!
stanrifkin: prior to v2 being there (a couple of months more at this rate), I will patch up v1 to use .^name instead of .WHAT 16:39
Voldenet hm, I think you can add Power to Length
m: multi infix:<+>(Int $x, Bool $y) { "foo" }; say 2 + True
camelia foo
librasteve Well that's not this use Physics::Measure :ALL; my $po = 24W; my $le = 4m; say $po + $le; 16:41
cannot convert in to different type Power 16:42
whereas you can (eg) add 3ft to 2m and so on
Voldenet m: class Power {}; class Watt is Power { }; class Time {}; class Seconds is Time {}; class Joule {}; multi sub infix:<*>(Power, Time) { Joule }; say Watt * Seconds
camelia (Joule)
Voldenet it's somewhat doable if you used base type for every unit kind 16:43
librasteve that's what Physics::Measure does
(nearly) 16:44
in fact seconds is a unit of Time
Voldenet well, Second is unit of Time, bit of typo
librasteve raku.land/zef:librasteve/Physics::Measure 16:45
the synopsis shows the classes in ()
so it infers that Distance / Time => Speed and so on
Voldenet hm, infix ops can do that 16:46
though they'd lose info about kilowatts and stuff like that
so km/h would become m/s
oh wait, the infix op could pick right unit prefix 16:47
librasteve yes, all the infix ops are overloaded in Physics::Measure to do just that
Voldenet m: class Power {}; class Watt is Power { }; class Time {}; class Seconds is Time {}; class Joule {}; class Kilojoule {}; multi sub infix:<*>(Power, Time) { if rand > .5 { Kilooule } else { Joule } }; say Watt * Seconds 16:48
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared name:
Kilooule used at line 1. Did you mean 'Kilojoule'?
librasteve not all, but all the main ones
Voldenet m: class Power {}; class Watt is Power { }; class Time {}; class Seconds is Time {}; class Joule {}; class Kilojoule {}; multi sub infix:<*>(Power, Time) { if rand > .5 { Kilojoule } else { Joule } }; say Watt * Seconds
camelia (Kilojoule)
librasteve not sure what you mean, (also I think Discord is mashing the infix within the <>) 16:49
Voldenet `class Power {}; class Watt is Power { }; class Time {}; class Seconds is Time {}; class Joule {}; class Kilojoule {}; multi sub infix:<*>(Power, Time) { if rand > .5 { Kilojoule } else { Joule } }; say Watt * Seconds`
that's probably better
librasteve yep ... that's what the module tries to do 16:50
Voldenet So if only Measure didn't contain the type, but was the type it would probably be a lot more useful
librasteve there is a drift towards (SI) Base units as you combine things - as you say km/h => m/s (unless you end with .in: 'km/h' if that's what you want 16:51
class Power is Measure is export {} <= from the source github.com/librasteve/raku-Physics...C1-L555C49 16:52
there arte about 50 sub-types - by inheriting then the overloads can be done together - multi infix:<*> ( Measure:D $left, Real:D $right ) is export {...} and so on 16:53
I have thought about parameterized roles with eg Measure['Power'], but so far subtypes has worked out best 16:55
Voldenet Hmm, so if only Measure was of the correct subtype, it would probably work 16:58
I mean `42m.WHAT.raku.say -> Physics::Measure::Length::Meters { value => 42, error => Error }` 17:00
librasteve 24W.WHAT.raku.say; => Physics::Measure::Power 17:01
^ this works fine
Voldenet except the type is not Power, it's Watts 17:02
librasteve (and originally .WHAT was fine ... something external changed)
17:02 jpn joined
Voldenet the problem is that .raku doesn't return the type, so you're forced to check for strings 17:03
librasteve no - the type is Power ... the Units have name watts, or PS or hp and so on
Voldenet Ah yes, currently it is Power, I was wondering if it shouldn't be Watts instead 17:04
librasteve no - because you can add hp to watts
Voldenet which should give you Power in SI 17:05
librasteve yes - that works fine 17:06
Voldenet so W + hp -> W
librasteve 24W.raku.say; # Physics::Measure::Power.new(value => 24 ... <= this is the preamble in the .raku - so it DOES have the type in the .raku, unless I misunderstand what you are saying 17:07
Voldenet which with inheritance would translate to `multi infix:<+>(Power $a, Power $b) returns Watt { }`
librasteve yes W+hp -> W unless you specify conversion of the result with .in
17:08 jpn left
Voldenet That's the detail I was going on about 17:08
librasteve no - multi infix:<+>(Power $a, Power $b) returns Power { }
Voldenet it could become `Physics::Measure::Power::Watt(value => 24)`
if Watt would inherit Power, it'd still be Power, then any addition using Power would return standard Watt 17:09
though the detail I don't quite get is why Measure has `units` field instead of unit 17:11
librasteve I suppose it would be possible to also subtype as Physics::Measure::Power::Watts, Physics::Measure::Power::hp and so on, I have chosen not to do that because I am using the type to control the errr physical type of the quantity - and there is a has a relationship to the Unit class (which specifies dimensions, conversion factors, synonyms and so on)
because I am English and not American and that's how we say it 17:12
the Length of my room is 14 in units of feet
Voldenet ah, it doesn't refer to `multiple units` in the case 17:13
makes sense
Eh, so now I think about it, the change I was proposing would be large and breaking 17:14
since Measure would start to inherit from Unit
librasteve and already there are nearly 300 types of units and it would take a LONG time for raku to make those classes on start up
Voldenet or something equally weird
300 classes… hm… is it really that slow? 17:15
librasteve well there is the type of the Measure (Power, Length, Time) and there is the Unit of the measurement (Watts, W, BTU, hp) ... 17:16
yep - I actually did this on version 1 and then had to rewrite - version 2 pre-made the objects and held them as pre-comp, but then the dev cycle has this issue - version 3 actually reads the definitions into a bunch of hashes and then makes the objects in a lazy way (only need the SI Base and Prefix which is about 30 objects now) ...here's a blog I wrote about it 17:19
rakujourney.wordpress.com/2021/01/...ysicsunit/
Voldenet I've checked and types themselves aren't that slow 17:21
librasteve so the released v1 is in reality v4 of the code, release v2 will be a refactor so that I understand what I wrote (;-)) and my vision for v3 is to use RakuAST & Macros to build all the objects directly
Voldenet m: class Unit { }; class Power is Unit { has Int $.v; }; my @u = (^1000).map({ my $u = Metamodel::ClassHOW.new_type(name => "Watt" ~ $_); $u.^add_parent(Power); $u.^compose; $u }); say now - BEGIN now 17:22
camelia 0.159770701
Voldenet maybe exporting them in the module would take longer
librasteve yes - but I run quite a complex Grammar to make each Unit class
Voldenet can't they be as lazy as they are now? 17:23
librasteve because the definitions are essentially plaintext - # Power ['us-horsepower', 'us-hp'], '550 foot pound-force / s', ['PS', 'horsepower', 'hp'], '75 kg * g0 * m / s', 17:24
Voldenet initially I was proposing that `CreateUnit` could simply do metamodel magic
(in Physics::Unit) 17:25
librasteve so to instantiate us-hp, I have to instantiate pound-force that is in terms of pound in terms of kg
Voldenet so $made-unit would be some constant value in created type inheriting from Unit 17:26
it messes up measurements a bit, because now it's possible to have `Physics::Measure::Power { units => Seconds }` 17:29
but that would need risky refactor probably 17:30
hm
> Physics::Measure::Power.new(value => 42, units => 1s.units).raku.say 17:31
it is possible now if someone's clever enough 17:32
librasteve this is the kind of change (ie API v1 to v2) that I would consider in one of these major rewrites --- right now I think that employing the typesystem to police the type of the measurement (so that it is obvious that you cannot add Power to Length and so on), I do not think that 'hardwiring' the types of each Unit variant is practical. Not only would we have to do this for all 300 units we have already, but I want 17:39
to extend the module to further embrace custom unit libraries such as CGS, localization 'Longueur' => ['m', 'mètre',] currencies and so on. Another practicality (which is one of the main drivers of the current refactor) is to allow non - predefined units ... what happens if you go Time / Distance => ? - there is no unit type for this as it is not a real thing --- but we need a way to handle types of intermediate results in
longer expressions with "synthetic" units so that they do not just fail
Voldenet `use Physics::Measure :ALL; class UnitBase { has $.units; has $.value; }; sub to-raku-unit($x) { my $u = Metamodel::ClassHOW.new_type(name => $x.units.defn.tc); $u.^add_parent(UnitBase); $u.^compose; $u.new(units => $x.units, value => $x.value); }; say to-raku-unit(42s).WHAT` 17:42
`(Sec)`
this doesn't have any cache for created types, so it creates the type on every invocation 17:43
but seems promising since it doesn't require any change in the library
librasteve OK, my plan is to use this MOP approach to setup Measure subtypes (Power, Length) and so on - that should fix the issue mentioned and cut out a lot of typing - thanks! 17:45
OK - I have been a bit wary of the MOP due to the black arts nature ... but I agree here would be a good use 17:46
Voldenet btw, units should really be an attribute, but I didn't want to figure out adding those - then value + type pair becomes the only stored thing 17:47
librasteve BUT - I am not convinced to hardwire Units as subtypes in a similar way ... for the reasons above and no doubt some others I can think of
Voldenet Well, hardwiring units as subtypes isn't difficult as presented above 17:49
though it might have some performance issues, hard to find out with one-liners 17:50
librasteve I am attracted to have a consumption model like my $po = 42 but Power['W'] .... ie to use role comp to join value and type
17:51 notna joined
but then I will still be missing error bars which are there today my $x1 = 12.5nm ± 1; 17:51
hmmm - maybe I just need a slang to pick up the chars between = and but 17:53
Voldenet I prefer current method tbh. it's elegant 17:56
17:58 jpn joined
librasteve well to get all the SI units (m, W, s) and prefix combos (ns, kW) and so on I am already jamming 540? symbols into the postfix operator namespace ... and that doesn't do things like 2ft or 4hpm since I draw the line at SI ... so I am drawn to a slang to generalise that and to bring in non-SI units ... food for thought 17:59
18:00 reportable6 left
appreciate the guidance, MOP here I come (and no doubt back for help before too long) 18:00
18:01 reportable6 joined 18:03 jpn left
Voldenet probably number symbols is not that big of a problem, but the act of changing the grammar 18:04
and rakuast probably will alter perf characteristics of everything
nonetheless, good luck with mro 18:05
antononcube @librasteve It has been for at least a year in my TODO to list make a Raku package that connects to Wolfram|Alpha. I plan to finish it soon. 18:10
The package name will be "WWW::WolframAlpha". 18:11
Ideally, with that packge certain units conversions and inner workings can be validated more easily. 18:12
librasteve my (stretch/vacuum) vision for raku would be to have zef include things like class Home { has Room $.rooms .= new(2.4) } and class Room { has Height $.height .= new(1.8m ±0.1) } so the small step that Physics::Measure etc makes is to provide a building block of common measurement system for our wider type system / module library where things have a physical manifestation ... since raku is an OS glue language it 18:30
would be natural to have multiple LSP variants of each class where the same API could be used to access some native instance or to shim an external set of capabilities such as those provided by WolframAlpha - that said I have no idea whether this vision is shared or if it leads anywhere -
my very limited experience with "WolframAlpha" at it's least typed orientation can take a string in the input box like 3ft + 2m and add them ... but so can the Google search box and it's a lot faster and cheaper. but then maybe there's a lot more to it than that
antononcube Bing and Amazon used Wolfam|Alpha at some point. I am not sure do they still do. I am not sure did Google use Wolfram|Alpha ever or considered it. 18:40
18:54 jpn joined 19:00 jpn left 19:10 Sgeo joined 19:43 notna left 19:51 jpn joined 19:57 jpn left
@librasteve Here is an output from "WWW::WolframAlpha" (in a Jupyter notebook): 20:11
cdn.discordapp.com/attachments/633...3fb80&
See github.com/antononcube/Raku-WWW-WolframAlpha . (I have to review it and write more documentation before submitting to Zef.)
20:41 squashable6 left, shareable6_ left, quotable6_ left, nativecallable6_ left, benchable6_ left, bisectable6_ left, statisfiable6 left, reportable6 left, notable6_ left, bloatable6_ left, unicodable6_ left, evalable6_ left, committable6_ left, tellable6_ left, releasable6_ left, linkable6_ left, sourceable6_ left, coverable6_ left, greppable6_ left 20:52 sjn left 21:09 sjn joined 21:18 jpn joined 21:23 jpn left 21:50 stanrifkin_ left 22:13 jpn joined 22:18 jpn left 22:26 jpn joined 22:30 jpn left 23:12 rir joined 23:27 jpn joined 23:28 Altai-man left 23:32 jpn left 23:39 kjp left 23:40 kjp joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!