[11:03] Andrew Hellershanks: Hello, everyone.
[11:05] Kayaker Magic: I've been asking for help getting a grid started the last few meetings, I'm happy to report that everything is working now.
[11:05] Ubit Umarov: good
[11:05] Andrew Hellershanks: Hello, Selby.
[11:06] Selby.Evans @grid.kitely.com:8002: hi everyone
[11:06] Andrew Hellershanks: Kayaker, good to hear. Did it turn out to be just a few incorrect ini settings?
[11:07] Kayaker Magic: Yes, it was confusion caused by moving a grid from one server to another, having to change the address.
[11:08] Kayaker Magic: The last problem was ExternalHostName in the Regions.ini files. I thought that was unimportant, so I left it with the old address.
[11:08] Ubit Umarov: lol
[11:08] Ubit Umarov: :)
[11:08] Kayaker Magic: But apparently no avatars can log on without it.
[11:08] Kayaker Magic: I thought it was only for the LSL GetURL function.
[11:09] Andrew Hellershanks: ExternalHostName is one of the more important settings.
[11:09] Kayaker Magic: I left it with the old address, because eventually the domain name moved to the new server and then I had to change it back again.
[11:10] Ubit Umarov: yeah but a name change can take more the 8 hours to propagate
[11:11] Vincent.Sylvester @hg.zetaworlds.com:8002: Gotta love dns caching
[11:11] Andrew Hellershanks: I've been lucky. I usually find DNS changes propagate rather quickly. I think it depends a little on the host where the changes are being made and how often they send out changes.
[11:11] Kayaker Magic: We tested on the new server with the IP address, then with a different name, then changed the DNS of the old name at the last minute to switch over.
[11:11] Ubit Umarov: oh dotnet6 can have again the old mono thing on dns cache
[11:12] Ubit Umarov: bby default some things will not expire it
[11:12] Ubit Umarov: them
[11:12] Ubit Umarov: the samm httpclient they want us to use now
[11:12] Ubit Umarov: great for a simple web client
[11:13] Ubit Umarov: useless as we use httpwebrequest
[11:13] Ubit Umarov: but thats another ghost waiting on the full update to net6
[11:13] Vincent.Sylvester @hg.zetaworlds.com:8002: That's something it took from windows, that nasty habit of caching dns even if you set the ttl to 5 minutes
[11:14] Ubit Umarov: ewl many decided to use tls of 1 min
[11:14] Ubit Umarov: namely all dynips and google servers
[11:14] Ubit Umarov: forgeting that dns alone is a big part of all internet trafic
[11:14] Ubit Umarov: total flood without caches
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002: At some point really should figure out what to do for testing on dotnet6 to make sure we don't have other hidden regressions elsewhere
[11:15] Vincent.Sylvester @hg.zetaworlds.com:8002: But that's a loaded question
[11:15] Ubit Umarov: well and abotu regressions, last week code changes :p
[11:16] Ubit Umarov: i did fix a issue on attachtemp premissions
[11:16] Andrew Hellershanks: Vincent, using it helps. Automatic tests won't guarantee that all regressions are caught.
[11:16] Ubit Umarov: mantis 9039
[11:16] Ubit Umarov: the permissions where lost when attaching to other than ower
[11:17] Ubit Umarov: i mean script permissions
[11:17] Vincent.Sylvester @hg.zetaworlds.com:8002: Over the last two years or so I have seen tests fail maybe three times, each time hinting at a potential problem, so they have some use. Though I do agree the current tests aren't great, but they aren't useless either. Makes figuring out what to do with them more difficult.
[11:18] Ubit Umarov: some still fail just because timing issues
[11:18] Vincent.Sylvester @hg.zetaworlds.com:8002: I did get most of them fixed up for the mono branch at least, even the performance tests
[11:18] Ubit Umarov: a few take ages just to avoid that
[11:18] Ubit Umarov: are there just waiting :)
[11:19] Ubit Umarov: but bahh all need to be updated to at least nunit 3.0
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002: Even made new ones for YEngine and for LSL compliance testing
[11:19] Ubit Umarov: or xunit or.. something
[11:19] Ubit Umarov: many consider nunit guess what.. obsolete :)
[11:19] Andrew Hellershanks: :)
[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002: Yeah that's the big question, update the current ones or write them from scratch. What's easier to do. I so far only managed to get the old ones to build with dotnet6 of course they cannot be run as is
[11:20] Ubit Umarov: well they are a lot
[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002: yep
[11:20] Ubit Umarov: still ignoreing them on dotnet6 branch
[11:21] Vincent.Sylvester @hg.zetaworlds.com:8002: It's funny they build, but neither nunit2 nor 3 will run them xD
[11:21] Ubit Umarov: did some code for it, but still chaning bc commit
[11:21] Ubit Umarov: a manual replacement for mono dllmap
[11:22] Ubit Umarov: something ms just did not port to net5+
[11:22] Ubit Umarov: well never had it
[11:23] Ubit Umarov: they just did add something that allows to "manualy" set "hooks" so code does load a unmanaged lib when needs
[11:23] Ubit Umarov: so adding a parser for the mono dll.confing things for that
[11:23] Ubit Umarov: liek others did
[11:24] Ubit Umarov: by manua li mean that we do need to add calls on the relevant assemblies
[11:24] Ubit Umarov: while mono did that automaticly
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002: cuga did end up getting dotnet6 branch to work natively on M1 mac if I recall, the info is posted on mantis
[11:25] Ubit Umarov: yes the main issue was to compile the native libs
[11:25] Ubit Umarov: he finally did that
[11:25] Ubit Umarov: for ubode, bullet and openjpeg
[11:26] Ubit Umarov: well openjpeng-dotnet
[11:26] Ubit Umarov: well openjpeg-dotnet
[11:27] Ubit Umarov: also fixe a timing initialization
[11:28] Ubit Umarov: had it on original miliseconds and stayed that way whne i changed everywhere to seconds tine unit :)
[11:28] Ubit Umarov: but was a self healing issue
[11:28] Vincent.Sylvester @hg.zetaworlds.com:8002: Prebuild now copying the system.drawing as well, nice bit of automation for building :)
[11:28] Ubit Umarov: wel that is temporary thing
[11:29] Ubit Umarov: need to put that on load code somewher
[11:29] Ubit Umarov: ugly thing :(
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002: That or rewrite everything that uses it to be system dependent...
[11:30] Ubit Umarov: as i said, seems ms now considers we must do one package per target platform/cpu
[11:30] Ubit Umarov: like we need to do on cpp
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Yeah they want to push nuget, so that you can make a mess like npm requiring hundreds of dependencies for just log output or whatever
[11:31] Ubit Umarov: while our code is like it was, one shared managed code base, same for all, with a few native parts loaded at runtime
[11:32] Ubit Umarov: that dllmap code i told about, is abotu this issue ofc
[11:32] Ubit Umarov: but that system.drawing...dll is managed
[11:32] Ubit Umarov: windows has its own that glues directly to win native code
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002: Someone was asking about postgres on irc the other day, made me remember what a mess nuget just making excuses for bad code really. When I tried updating the postgres connector with a new version from nuget it blew up everywhere. Not sure what MS is thinking, but this whole dependency thing with nuget just invites bad and lazy code. Kind of an unsure future in regards to the database connectors still
[11:33] Ubit Umarov: while linux needs more code to glue to libgdiplus
[11:33] Ubit Umarov: well i did some updates on libs from nuget
[11:33] Ubit Umarov: got the packets, and took out the libs i wanted
[11:34] Ubit Umarov: that system.drawing was sunc a case :)
[11:34] Ubit Umarov: same for mysql etc
[11:34] Ubit Umarov: i just consider nuget a pure nonsense
[11:34] Ubit Umarov: WE DO NOT WANT AUTOMATIC updates EVER
[11:35] Ubit Umarov: that is a huge software security hole
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002: Just like npm pretty much
[11:35] Ubit Umarov: security on a more broad sense, like getting fresh new bugs
[11:35] Ubit Umarov: without knowing about it
[11:36] Andrew Hellershanks nods
[11:36] Ubit Umarov: automatic updates are jsut BAD
[11:36] Ubit Umarov: ms ofrces them on windows ofc
[11:36] Ubit Umarov: but on win they are just needed
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002: In case of updating the postgres connector it required additional dependencies even just one version up, if I went to latest it was dependencies galore. Total mess and still wouldn't work right.
[11:37] Ubit Umarov: but ms does that on YOUR machine
[11:37] Ubit Umarov: o hope they do not update all the code base used on win like that :)
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: There is performance to be gained with better database connectors, but the expense is unsafe code and hacks that cause a mess
[11:38] Ubit Umarov: wel some of those hacks are more legal o n .net6
[11:38] Ubit Umarov: in fact used everywhere on it
[11:38] Ubit Umarov: another stupidity
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: I been wanting to update them, but every time I look I just lose hope at the mess I would have to untangle
[11:38] Ubit Umarov: see... they have rules..
[11:38] Ubit Umarov: like arrays bounds checks, etc
[11:39] Ubit Umarov: then add tricks to work around that
[11:39] Ubit Umarov: and do even suicidal things
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002: Why do data checks, no one ever could possibly attempt to parse bad data...
[11:40] Ubit Umarov: like tell compiler that a string is after all a array of floats
[11:40] Ubit Umarov: just bad..
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: drop_table:students all over again
[11:40] Ubit Umarov: they are doing a mess, because nonsense religion dogmas like forced array bounds checks
[11:41] Ubit Umarov: a lot of ppl would just not use unsafe code if could tell jot to not do them on a legal form
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002: For postgres the connector code is not too complex, one could try to write those parts out, but then we would be maintaining even more code which is kinda the point of these not to have to maintain them as well
[11:43] Ubit Umarov: return Unsafe.As<byte, short>(ref Unsafe.Add(ref MemoryMarshal.GetArrayDataReference(bytes), pos));
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002: I think in mono 5 postgres works fine, starting somewhere with mono 6 it stopped working, not sure which version exactly
[11:43] Ubit Umarov: and to do that is a a must lol
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002: My eyes have fallen out of their sockets
[11:44] Andrew Hellershanks: eek
[11:45] Ubit Umarov: thats does same as unsafe{fixed byte* b = &bytes[pos]; return *(short*)b
[11:45] Ubit Umarov: or more or less that :)
[11:46] Ubit Umarov: but doign it on managed domain, not doign the full fixed things
[11:46] Ubit Umarov: ofc will blow up if bytes[] is not hold in place and gc takes it out :)
[11:47] Ubit Umarov: .net6 gc did learn a bit more abt such things
[11:47] Ubit Umarov: that prettly code ends up as 2 machine code instructions
[11:48] Ubit Umarov: or 3
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002: I feel like some of that nonsense ultimately just drives people to things like Rust
[11:48] Ubit Umarov: ( in release mode and with ful jit opt)
[11:49] Ubit Umarov: well those lines where from current libomv :)
[11:49] Ubit Umarov: i change several parts from the "fixed" to that
[11:49] Ubit Umarov: master libomv uses fixed
[11:50] Ubit Umarov: this things are a must on binary serialization
[11:50] Ubit Umarov: for example
[11:51] Ubit Umarov: that was from public static unsafe short BytesToInt16(byte[] bytes, int pos)
[11:51] Ubit Umarov: :)
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: They probably think runtime errors aren't so bad, cause you can just restart, but for OpenSim runtime errors is what we have to avoid as much as possible
[11:52] Andrew Hellershanks: Indeed
[11:52] Ubit Umarov: well soft is a huge mess
[11:52] Ubit Umarov: and will not get any better
[11:52] Ubit Umarov: complexity just grows
[11:53] Ubit Umarov: but damm silly religion like those array bounds.. GRRR hate it
[11:53] Ubit Umarov: fortran and c never had it.. cobol did
[11:53] Ubit Umarov: and its fine for cobol market
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002: Clawed a lot of stability back though over the years, losing that to some suicidal code in dependencies is not nice
[11:54] Ubit Umarov: alos fine if by default c does it
[11:54] Ubit Umarov: bt why not a damm metadata telling jit to not do it
[11:54] Ubit Umarov: like the inline has:
[11:54] Ubit Umarov: [MethodImpl(MethodImplOptions.AggressiveInlining)]
[11:55] Ubit Umarov: why not a damm MethodImplOptions.NoBoundsCheck
[11:55] Ubit Umarov: bah irritating issue
[11:55] Ubit Umarov: to see bounds change take more cpu time than actual work on many cases
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: Between a rock and a hard place with those things, no good way out without making some concessions which is annoying yeah
[11:56] Ubit Umarov: well and they make JIT waste time looking to a few failed cases where it does take the checks automaticly
[11:56] Ubit Umarov: well nm
[11:57] Ubit Umarov: just very low end things :)
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: Lot of development moves that way lately, tons of dependencies, some lazy code and let the hardware apologize for the shit code
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: An odd shift in priorities
[11:58] Ubit Umarov: well cpus are damm complex things now also
[11:58] Ubit Umarov: and pretend to be clever
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: That's why arm is so fast, less bloat
[11:58] Ubit Umarov: we tell them do a then do b, and they do b than a
[11:59] Ubit Umarov: and a old issue
[11:59] Ubit Umarov: that in part killed DEC
[11:59] Ubit Umarov: with the dec alpha cpu
[11:59] Ubit Umarov: we told it int a = 4;
[11:59] Ubit Umarov: b = a + 3;
[12:00] Ubit Umarov: and the damm cpu did b = a +4; a = 4
[12:00] Ubit Umarov: with a undefined... bahh
[12:00] Ubit Umarov: and this already in 90's
[12:01] Ubit Umarov: wel lpossible some big machines did it also in late 60's :)
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002: Like javascript, just worse lol
[12:02] Ubit Umarov: thats 'aout of order execution optimization" at cpu
[12:02] Ubit Umarov: out of order..
[12:02] Ubit Umarov: compilers need to fix those issues.. fun
[12:03] Andrew Hellershanks: Yes, they should.
[12:03] Ubit Umarov: but what news do you have abt opensim ?
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: Anyways I had a look at groups code finally, did find two things that had me go "huh?", have to dig a bit see if I can rewrite those things, think they are part of the reason why it is slow. Though in the sql parts at least there is nothing immediate I could see, so I need to dig deeper into those parts
[12:04] Ubit Umarov: goups v2 has a lot of "huh?"
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: The database connector for it is very generic so it ultimately does nothing to improve queries
[12:04] Ubit Umarov: flotsam also.. just a bit less
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: Have to see if I can rewrite parts of that so it can use sql more effectively
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: Just a big task to understand the thing enough to do that and my time isn't unlimited sadly
[12:05] Ubit Umarov: effectively and sql fit on same text line?
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: It does a generic select *, which might not be the fastest way to get the data it needs for the call it has to run
[12:06] Ubit Umarov: unless "sql is pure deny of effectively"
[12:06] Andrew Hellershanks: There are some complex queries in groups.
[12:06] Ubit Umarov: :)
[12:06] Vincent.Sylvester @hg.zetaworlds.com:8002: say it only needs to get data from two tables, joining them at sql level is often faster than in code
[12:06] Vincent.Sylvester @hg.zetaworlds.com:8002: Course all depends on situation hence first trying to understand the whole thing
[12:06] Ubit Umarov: unless user decides to put them on dif mysql
[12:07] Ubit Umarov: as some tell to do...
[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002: Ideally it would run on a document db, just fetch the document by uuid, but I don't want to do that just yet
[12:07] Ubit Umarov: the opensim idea of "microservices"
[12:08] Ubit Umarov: ~that ofc fails a lot more than "those"
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: I think just changing the database connector to not be just doing generic query select * might already help quite a bit
[12:08] Ubit Umarov: bc databases interdependecies kill it all
[12:09] Ubit Umarov: well to not do searchs wit uas could help a lot
[12:09] Ubit Umarov: searchs by...
[12:10] Vincent.Sylvester @hg.zetaworlds.com:8002: It needs to do a few strategic joins and only select the data it actually needs instead of everything each time, adjust the code to fetch things and store them with less type conversions
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002: That alone might double the speed
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002: Database itself is fast getting data, even on millions of rows, kinda their purpose so they do that well
[12:11] Kayaker Magic: I need to boogie, RL calling.
[12:11] Ubit Umarov: who did test dotnet 6 here?
[12:11] Ubit Umarov: any?
[12:12] Andrew Hellershanks: ok, Kayaker. Thanks for droppping by.
[12:12] Ubit Umarov: u can tell him that next week :)
[12:12] Andrew Hellershanks: It is now a quarter past the hour. Are there any other last minute items for today?
[12:12] Andrew Hellershanks: Ubit :)
[12:13] Andrew Hellershanks: I didn't hear Kayaker's transporter noise before he left.
[12:14] Andrew Hellershanks: Vincent, you have your work cut out for you if you want to tackle those SQL queries in groups.
[12:14] Vincent.Sylvester @hg.zetaworlds.com:8002: I am starting to see the light of sql lol
[12:14] Selby.Evans @grid.kitely.com:8002: bye all
[12:15] Andrew Hellershanks: ok, bye Selby.
[12:15] Ubit Umarov: cya
[12:15] Andrew Hellershanks: As there isn't any last minute items for today I'll conclude this meeting.
[12:15] Andrew Hellershanks: Thank you all for coming. See you again next week.
