Chat log from the meeting on 2020-11-24

From OpenSimulator

Jump to: navigation, search

[11:02] Ubit Umarov: thanksgiving no?
[11:02] Gavin.Hird @grid.xmir.org:8002: Hi Andrew
[11:02] Ada Radius: yes
[11:02] Ada Radius: turkey and unimaginable amounts of carbs
[11:02] Gavin.Hird @grid.xmir.org:8002: the start of the shopping season
[11:02] Chat Logger: Meeting chat logging has been enabled.
[11:02] Chat Logger: You can view the log at: https://web.youcantfixstupid.wtf/outreach/index.php
[11:03] Andrew Hellershanks: Hello, everyone.
[11:03] Ada Radius: Hi Andrew
[11:03] Ubit Umarov: ahh andrew's cat did call him
[11:03] Selby.Evans @grid.kitely.com:8002: Big celebration on Jan 20 -- like Chrinsmas in January
[11:03] Ubit Umarov: hi andrew
[11:03] Selby.Evans @grid.kitely.com:8002: Hi Andrew
[11:03] Gavin.Hird @grid.xmir.org:8002: Chringemas?
[11:03] Ubit Umarov: oh in Jan also?
[11:03] Andrew Hellershanks: I almost got a little too carried away watching a video about setting up a Raspberry Pi to emulate an Amiga.
[11:04] Gavin.Hird @grid.xmir.org:8002: sounds exciting Andrew
[11:04] Gavin.Hird @grid.xmir.org:8002: I got mono compiled from source on the M1
[11:04] Andrew Hellershanks: Nice.
[11:04] Gavin.Hird @grid.xmir.org:8002: it performs as fast as my machine with a 12 core Xeon
[11:05] Ubit Umarov: you are no longer supposed to run a xeon at 10Mhz gavin.Hird
[11:05] Gavin.Hird @grid.xmir.org:8002: now trying to compile the rest of the libs to get opensim running on it
[11:06] Andrew Hellershanks: The past couple of days I fired up my standalone install of OpenSim and loaded up another region to work on a train system I had tried out a while ago. I also tried YEngine and found something "interesting" but not in a good way.
[11:06] Gavin.Hird @grid.xmir.org:8002: the Laserwriter had a 12 Mhz processor. At the time it was the fastest computer Apple made.
[11:07] Andrew Hellershanks: 10MHz? Wast that a typo?
[11:07] Ubit Umarov: no was a tease :p
[11:07] Andrew Hellershanks: :)
[11:07] Gavin.Hird @grid.xmir.org:8002: but it cut down the time to print a particular document from about 95 minutes to 3
[11:07] Ubit Umarov: possible 10 mhs is below minimal clock of xeons
[11:08] Ubit Umarov: 10mhz
[11:08] Ubit Umarov: those things are not static cpus, if i remember well
[11:08] Gavin.Hird @grid.xmir.org:8002: hehe
[11:08] Andrew Hellershanks: You just made me remember I need to order a 10MHz crystal oscillator package.
[11:08] Andrew Hellershanks: Hey, Kayaker.
[11:08] Ada Radius: Hi Kayaker
[11:08] Ubit Umarov: slow clock.. poff cpu registers lose contents etc
[11:08] Gavin.Hird @grid.xmir.org:8002: someone ran DOS boot in emulation, and it took about a week to get to the dos prompt
[11:09] Kayaker Magic: Hello all
[11:09] Andrew Hellershanks: hehe
[11:09] Gavin.Hird @grid.xmir.org:8002: can't remember what the setup was
[11:09] Ubit Umarov: a z80 at 2mhz?
[11:09] Gavin.Hird @grid.xmir.org:8002: IDK
[11:09] Ubit Umarov: well even that should do it in less time
[11:10] Gavin.Hird @grid.xmir.org:8002: it should
[11:10] Andrew Hellershanks: I would think so too.
[11:11] Ubit Umarov: i remember testing games in emultators.. using i got GameEnd before ending the start click
[11:11] Selby.Evans @grid.kitely.com:8002: Just got a notice from Kitely: Today we had a world crash on Tessin. It seems there is a big in Ubode Ode physics engines that needs to be fixed. Ilan wrote me this will be done in the next roll out . Until then , wear a life jacket :)
[11:11] Ada Radius: ouch
[11:11] Andrew Hellershanks: Did they provide any other details about what is the bug in ubODE?
[11:11] Ubit Umarov: well we do have mantis..
[11:11] Kayaker Magic: Windows was never very efficient, I assume Dos wasn't either. I've watched Windows in emulation re-draw the screen multiple times for no apparent reason.
[11:12] Selby.Evans @grid.kitely.com:8002: No further info, but Ilan knows what it is.
[11:12] Andrew Hellershanks: It is interesting what you can learn about a system when you slow it down.
[11:12] Gavin.Hird @grid.xmir.org:8002: perhaps Kitely would be good enough to report it the person who write UbOde?
[11:12] Ubit Umarov: but we got no feedback from kitely, guess in years
[11:13] Ubit Umarov: i got some emails with questions.. after 0.9.1.1 upgrade, but no feedback
[11:13] Ubit Umarov: seems kitely is more in the game of own fixes
[11:13] Ubit Umarov: comercial things..
[11:13] Kayaker Magic: Writing good bug reports is hard. If you have a full time job, or a company to run, I suspect you never have time to do that.
[11:14] Ada Radius: Ilan did mention you at the last meeting on Sunday - gratitude for maintaining the OS code
[11:14] Ubit Umarov: main thing about ubode and old ode is threads max stack on linux
[11:15] Ubit Umarov: that needs to be set on shell before start
[11:15] Ubit Umarov: old thing
[11:15] Ubit Umarov: regions with many colisions may use all stack memory
[11:15] Ubit Umarov: and that is a big crash :)
[11:15] Ada Radius: reporting bugs tends to be thankless. Responses go through all the stages of grief: denial, anger, bargaining, etc
[11:16] Andrew Hellershanks: hehe
[11:16] Ubit Umarov: opensim.sh as the needed shell comand example
[11:16] Ubit Umarov: and has
[11:16] Andrew Hellershanks: From my testing the other day I have several bug reports to file.
[11:17] Selby.Evans @grid.kitely.com:8002: Ilan did say they found a bug in ODE that carried over into UbODE. It was something that rarely happened except now in the 8x8 sims.
[11:18] Ubit Umarov: ok
[11:21] Ubit Umarov: will wait a mantis :)
[11:21] Ubit Umarov: or something
[11:21] Ubit Umarov: with details i can look into
[11:22] Gavin.Hird @grid.xmir.org:8002: telepathy
[11:22] Andrew Hellershanks: Has anyone else noticed a major difference in CPU usage on a machine when using YEngine vs XEngine?
[11:22] Kayaker Magic: I was thinking perhaps someone (I could try to volunteer for this) could talk to Ilan or Owen about some of these bugs. Perhaps in conversation they would communicate enough to narrow it down....
[11:23] Ubit Umarov: that should not be the direction of bugs information flow Kayaker
[11:23] Ada Radius: Good idea Kayaker
[11:23] Ubit Umarov: during the debug, that maybe needed
[11:24] Ubit Umarov: i went to several grids to debug issues
[11:24] Ada Radius: As I said to another dev making the same complaint; good communication has to go in both directions
[11:24] Ubit Umarov: and will go
[11:24] Selby.Evans @grid.kitely.com:8002: Apparently not much of a problem since has not been found till now. Kayaker -- please volunteer to ask Ilan -- I would, but probably would not understand the answer
[11:24] Gavin.Hird @grid.xmir.org:8002: I actually find it astonishing that Kitely, which capitlaizes (literally) on the work of the opensim dev(s) have chosen not to communicate or even contribute anything for eyears
[11:24] Gavin.Hird @grid.xmir.org:8002: shame on them
[11:24] Ada Radius: (I was not defending Ilan, he can be prickly too)
[11:24] Ubit Umarov: for now only have selby.Evans good words :)
[11:25] Ubit Umarov: well they are not the only ones..
[11:25] Ada Radius: Ask Ilan why, but be prepared for intelligent things you may not want to listen to.
[11:25] Gavin.Hird @grid.xmir.org:8002: no, but you know what I mean
[11:26] Ubit Umarov: Trading, usually implies that
[11:26] Ada Radius: How often do donated patches get accepted? If the answer is hardly ever, then you can't blame people for giving up on donating them
[11:26] Ubit Umarov: each whats to have a better "product"
[11:27] Kayaker Magic: Rather than assume a conspiracy to explain a lack of communication from Kitely, I always assume a lack of time and personell.
[11:27] Ada Radius: that too.
[11:27] Ubit Umarov: actually think recent acceptance rate is 2 high err i mean high :p
[11:27] Ubit Umarov: yeah last for years kitely ?
[11:27] Ubit Umarov: lasting..
[11:28] Ubit Umarov: well whatever..
[11:28] Ubit Umarov: at leat they keep opensim name, unlike others
[11:29] Ada Radius: Ilan and Oren are both reasonable people, Oren is brilliant. Both very very busy. If you reach out to them you'll probably be able to come to an agreement.
[11:29] Andrew Hellershanks: Last time I spoke with Ilan they said they are busy with updating Kitely and getting all the bugs fixed but they would provide some patches later. Presumably once they are no longer busy dealing with all the bugs they are dealing with currently.
[11:29] Gavin.Hird @grid.xmir.org:8002: agreement?
[11:29] Gavin.Hird @grid.xmir.org:8002: is there a conflict?
[11:30] Ada Radius: You seemed to be saying that there is a conflict - they're writing patches that you want?
[11:30] Kayaker Magic: If you want to see more patches Ubit, perhaps you could demonstrate how to do that by submitting all your changes as a series of patches.
[11:30] Gavin.Hird @grid.xmir.org:8002: If Kitely see and issue that enrally effects all of opensim, they should git the issue into Mantis and use the standard procedure to get it resolved
[11:31] Gavin.Hird @grid.xmir.org:8002: generally*
[11:31] Selby.Evans @grid.kitely.com:8002: They keep introducing products and those show up new bugs -- We like the products.
[11:31] Kayaker Magic: You (Ubit) will say making those patches is too much trouble. That is all that Kitely is saying.
[11:31] Ada Radius: yes we do. and the bug fixes.
[11:34] Ubit Umarov: i will say what?
[11:34] Ubit Umarov: whatever
[11:34] Andrew Hellershanks: Ubit, I switched my standalone from YEngine back to XEngine and the CPU load has dropped considerably. I was at 285% average on one mono thread under YEngine. With XEngine the highest CPU load frmo a mono process is only 55% average.
[11:35] Ubit Umarov: yes yengine will try to run scripts..
[11:35] Ubit Umarov: :p
[11:35] Andrew Hellershanks: There are a number of bad scripts in the oar file I loaded that I need to look at. I didn't expect to see such a different CPU load.
[11:35] Ubit Umarov: wonder how a mono thread can use 2.85 cores..
[11:36] Ubit Umarov: try look to stats to see what scripts use cpu
[11:36] Andrew Hellershanks: Don't know but it shows that one of the threads is exceedingly busy under YEngine.
[11:36] Ubit Umarov: X kiils a long event
[11:37] Ubit Umarov: Y will keep it running
[11:37] Gavin.Hird @grid.xmir.org:8002: no setting for that on Y?
[11:37] Ubit Umarov: some events may still not yield execution.
[11:38] Ubit Umarov: no Y is supposed to support long events
[11:38] Andrew Hellershanks: IIRC, some of the scripts are using llSensor
[11:38] Ubit Umarov: doing time slice ofc
[11:38] Gavin.Hird @grid.xmir.org:8002: for X you can set the duration of a long even peer simulator
[11:38] Gavin.Hird @grid.xmir.org:8002: event per*
[11:38] Ubit Umarov: yes and kill that script
[11:39] Andrew Hellershanks: I need to remember how to pull up the stats.
[11:39] Ubit Umarov: bc that limit can leave global things in a underterminated state
[11:40] Gavin.Hird @grid.xmir.org:8002: I suppose it is possible to do the kill gracefully
[11:40] Ubit Umarov: underterminated ??
[11:40] Andrew Hellershanks: Nice word. :)
[11:40] Ubit Umarov: undefined is better there
[11:41] Andrew Hellershanks: or indeterminate
[11:41] Ubit Umarov: yeah
[11:41] Ubit Umarov: one day i may add a Yield keywork
[11:41] Gavin.Hird @grid.xmir.org:8002: viewer has a ton of code to clean up stuff that terminates, in addition to when the viewer exits
[11:41] Andrew Hellershanks: I know some people that had set the allowed script run time to a really high value. I think they are doing too much in the timer event handler.
[11:41] Ubit Umarov: identical to what win31 and similar os had
[11:42] Ubit Umarov: think all windows until 95 dependend on apps to yield execution to to multitask
[11:42] Ubit Umarov: like Y
[11:43] Andrew Hellershanks: IIRC, that is called cooperative multi-tasking.
[11:43] Ubit Umarov: but even with yield, if there are scripts with endless looks, Y will do them full speed
[11:44] Ubit Umarov: if more than one like that 2 threads busy that is 200% cpu
[11:44] Ubit Umarov: more or less
[11:45] Andrew Hellershanks: I went in to Top Scripts when running YEngine but nothing was listed. I see about a dozen or so scripts with a runtime of more than 1 under XEngine that I will be looking at more closely.
[11:45] Andrew Hellershanks: I didn't write the scripts in the oar file.
[11:46] Ubit Umarov: those redution errors you mentioned are just script compile errors
[11:46] Kayaker Magic: I like to say that all the free scripts you get from SL are never worth what you paid for them, usually a LOT LESS.
[11:46] Gavin.Hird @grid.xmir.org:8002: :-)
[11:46] Andrew Hellershanks: Errors or just warnings?
[11:46] Ubit Umarov: Y error messages can be strange still
[11:46] Ubit Umarov: erros
[11:47] Andrew Hellershanks: It made me think of messages when parsing a grammar using Lex or Yacc.
[11:47] Ubit Umarov: script errors detected later..
[11:47] Andrew Hellershanks: I'll see if I can find those scripts to determine why they cause errors.
[11:47] Gavin.Hird @grid.xmir.org:8002: like the classic: an error occurred because an error occurred
[11:47] Andrew Hellershanks: hehe
[11:47] Ubit Umarov: and didn't understud your point abot the ||| and &&&
[11:48] Andrew Hellershanks: I don't know of any programming language using those operators. It looks like a typo.
[11:48] Ubit Umarov: it is not
[11:48] Andrew Hellershanks: It is not?? What do they do vs. regular || and &&?
[11:49] Ubit Umarov: normal || must stay as LSL, doing evealuation of a entire expression
[11:49] Ubit Umarov: ||| will just out of FIRST satisfies the condition alone
[11:49] Ubit Umarov: wil jump out i mean
[11:50] Ubit Umarov: wel in if case jump in
[11:50] Ubit Umarov: so the need for both variants
[11:50] Andrew Hellershanks: :P When I read that YEngine will do short cuts I thought that was a default behaviour.
[11:50] Ubit Umarov: can't be
[11:51] Andrew Hellershanks: Why not? You think it will break too many scripts?
[11:51] Ubit Umarov: possible
[11:51] Ubit Umarov: this way coder can decide where
[11:51] Ubit Umarov: and if does past old lsl code, it will work
[11:52] Ubit Umarov: bc || and && on it will work as before
[11:52] Andrew Hellershanks: Until everyone switches to YEngine that is going to make scripts non-portable between grids if someone wants to use them.
[11:52] Ubit Umarov: ||| is Y specific
[11:52] Ubit Umarov: you need to set yoptions
[11:52] Kayaker Magic: No Andrew, || continues to work as before. Nothing breaks.
[11:52] Ada Radius: Sry got to do deal with RL
[11:53] Ubit Umarov: yes and will still work as before even with yoptions
[11:53] Ubit Umarov: bc as i said parts of the script may be old lsl
[11:53] Andrew Hellershanks: No, I'm saying if someome writes a script where they want to shortcut expression evaluation and makes use of those operators they can't use those scripts on another grid unless that grid is running YEngine and supports that feature.
[11:54] Ubit Umarov: what part of they could not use it anyways?
[11:54] Ubit Umarov: once they add yoptions do have shortcuts avaiable?
[11:54] Andrew Hellershanks: You are saying that ||| defaults to || behaviour in YEngine unless they enable a setting in the YEngine configuration section?
[11:55] Ubit Umarov: You just CAN't use without setting yoptions
[11:55] Ubit Umarov: gez you keep forgetting yoptions keyword
[11:55] Ubit Umarov: rtfm :p
[11:56] Ubit Umarov: hi amvans.Lapis
[11:56] amvans.Lapis @grid.kitely.com:8002: Hello!
[11:56] Andrew Hellershanks: Welcome, amvans
[11:56] Ubit Umarov: well bout code changes last week
[11:56] Ubit Umarov: no many
[11:57] Ubit Umarov: i got into a can of worms on hg
[11:57] Kayaker Magic: Andrew there are lots of things that cause scripts to fail on one grid or another, like calling OSSL functions. New Y syntax is just another of those.
[11:57] Andrew Hellershanks: Ubit, the web page says how to enable the short cutting feature. It doesn't say how YEngine will treat those operators if the yoption is not set.
[11:57] Ubit Umarov: you still don't understand yoptions
[11:58] Ubit Umarov: try to read again
[11:58] Ubit Umarov: no yoptions no ||| so.. compile error
[11:59] Ubit Umarov: well i tried to make hg more robust to grids that may have diferent hosts
[11:59] Ubit Umarov: and had some issues
[11:59] Ubit Umarov: hope better now
[12:00] Ubit Umarov: a typical case is login.osgrid.org and hg.osgrid.org
[12:00] Ubit Umarov: osgrid like others want first for direct logins, second for hg tps
[12:00] Ubit Umarov: old code would consider those diferent grids
[12:01] Ubit Umarov: well HG fun things
[12:01] Andrew Hellershanks: Ubit, I will update the wiki pages to point out that use of the operators without having set yoptions will result in YEngine throwing an error. It doesn't say that currently.
[12:02] Ubit Umarov: yeah and going to add it to all extensions, when is is clear they are not avaiable without it
[12:03] Ubit Umarov: also did a fix on user language store
[12:03] Andrew Hellershanks: It is a shame we are still saddled with mistakes made by the person(s) who made the LSL parsers not support short cutting of execution and also made eval order be right to left.
[12:04] Ubit Umarov: problem is more lack of coerency on that
[12:04] Ubit Umarov: (((()))) are your friend on those
[12:04] Ubit Umarov: also not that ONLY one expression does short cuts
[12:05] Ubit Umarov: (C# also )
[12:05] Ubit Umarov: actually not sure what X did
[12:05] Andrew Hellershanks: What do you mean by "only one expressin"?
[12:05] Ubit Umarov: possible did shortcuts all the time
[12:05] Ubit Umarov: using c# rules
[12:06] Ubit Umarov: that is only a issue when people is overcleaver on expressions
[12:06] Ubit Umarov: always baad idea on any languague
[12:07] Ubit Umarov: we should keep them simple and using ( ) as needed also to make it more readable
[12:07] Ubit Umarov: ( look to what i say not what i do :p )
[12:08] Kayaker Magic: LOL
[12:08] Andrew Hellershanks: It is not unreasonable in an if statement (for e.g.) to see a test for NULL pointer before doing a deref using that pointer. If there is no short cutting the code would often fail on seg faults.
[12:08] Andrew Hellershanks: hehe
[12:09] Andrew Hellershanks: We just passed the top of the hour. Does anyone have a question or comment to make before they need to leave?
[12:09] Gavin.Hird @grid.xmir.org:8002: well
[12:09] Andrew Hellershanks: Any questions or comments from anyone who doesn't need to be leaving shortly?
[12:10] Gavin.Hird @grid.xmir.org:8002: new Win viewer posted last week with My Suitcase issue fixed
[12:10] Ubit Umarov: ahh yes
[12:10] Ubit Umarov: last week and Beq and gavin added a hack to fix a 5yrs old issue with suitcate
[12:10] Gavin.Hird @grid.xmir.org:8002: lo and behold it now shows after Beq Janus did some digging for a very obscure error
[12:10] Ubit Umarov: suitcase :)
[12:11] Ubit Umarov: it was me and beq :p
[12:11] Gavin.Hird @grid.xmir.org:8002: the missing suitcase
[12:11] Andrew Hellershanks: No more lost luggage. :)
[12:11] Gavin.Hird @grid.xmir.org:8002: that was brilliant detective work by the two of you
[12:11] Ubit Umarov: well think is that we set suitcase folder type to 100.
[12:12] Gavin.Hird @grid.xmir.org:8002: sure, but it was a compiler issue
[12:12] Ubit Umarov: since 2015 , on a 0.8,.2.1 release
[12:12] Gavin.Hird @grid.xmir.org:8002: some compilers, like Clang handled it perfeectly fine, VS not so
[12:12] Ubit Umarov: happens that inventory has filters
[12:12] Gavin.Hird @grid.xmir.org:8002: gcc handled it fine too
[12:13] Ubit Umarov: and to do those filters, ll decided to convert the types to a bit mask on a 64bits long
[12:13] Ubit Umarov: so the mask for a folder type is ( 1 << type )
[12:13] Ubit Umarov: happens that (1 << 100 ) is.. well bad :)
[12:14] Ubit Umarov: in most compilers that will be 0
[12:14] Ubit Umarov: but depends on how low level does the 64bit shift
[12:15] Ubit Umarov: on 64 cpus running in 64bit that can be a single instruction
[12:15] Ubit Umarov: 32b more complex
[12:15] Ubit Umarov: well with result 0 suitcase would be always insible
[12:15] Ubit Umarov: but there is a fun twist
[12:16] Andrew Hellershanks: hm... there are three other inventory folder ID's that only work for a 64-bit value.
[12:16] Ubit Umarov: actual code is ((1<< type) & amask ) == 0)
[12:16] Ubit Umarov: compliers for intel cpus in 64b are cleaver and see that is actually a intel bit test instruction
[12:16] Gavin.Hird @grid.xmir.org:8002: which 3 folders are those Andrew?
[12:16] Andrew Hellershanks: Current Outfit is 46, Outfits is 47, and Meshes is 49.
[12:17] Ubit Umarov: in this case like bt mask, 100
[12:17] Gavin.Hird @grid.xmir.org:8002: Meshes?
[12:17] Ubit Umarov: and on nit test that is the same as bt mask,36
[12:17] Ubit Umarov: and that worked
[12:17] Gavin.Hird @grid.xmir.org:8002: is that used by any viewer at all?
[12:17] Ubit Umarov: suitace was visible, ( as long type 36 was)
[12:17] Andrew Hellershanks: Don't know but those three folder types are listed in the wiki.
[12:17] Ubit Umarov: so we never did notice on 64bit
[12:18] Gavin.Hird @grid.xmir.org:8002: Currrent outfit should work
[12:18] Ubit Umarov: we tested and worked :)
[12:18] Andrew Hellershanks: Gavin, if you have a 64 bit value. It would fail on 32bit if it is 1<<type.
[12:18] Gavin.Hird @grid.xmir.org:8002: but Outfit and Meshes I have never seen anywhere
[12:18] Ubit Umarov: until some using 32b noticed that suicase was invisbile
[12:19] Ubit Umarov: and filed a firestorm jira
[12:19] Ubit Umarov: well was fun bug
[12:19] Ubit Umarov: as i said, Beq and gavin now just test the case 100 on its own
[12:19] Andrew Hellershanks: I would expect Current Outfit to fail on 32-bit.
[12:19] Ubit Umarov: that may mean we can't hide suitcase ever
[12:20] Ubit Umarov: you expect wrong
[12:20] Ubit Umarov: :p
[12:20] Andrew Hellershanks: 1<<49 is going to exceed 32-bits.
[12:20] Gavin.Hird @grid.xmir.org:8002: I'll have to do the same for current outfit if it does not work, but AFAIK it does
[12:20] Ubit Umarov: what part of a 64bit integer you missed?
[12:20] Ubit Umarov: gezz
[12:20] Andrew Hellershanks: Perhaps there is some other special handling in the code.
[12:21] Andrew Hellershanks: Ubit, what part of this would fail under 32-bit did you miss?
[12:21] Ubit Umarov: NO it will not fail!!
[12:21] Gavin.Hird @grid.xmir.org:8002: the SL viewer is also in 32-bit Win version, and they would have caught it a long time ago if Current outfit did not work
[12:21] Ubit Umarov: c++ suports long long
[12:21] Ubit Umarov: gezzz
[12:21] Gavin.Hird @grid.xmir.org:8002: but I'll check
[12:21] Andrew Hellershanks: How can you shift a bit 49 places whn you only have 32-bits?
[12:21] Ubit Umarov: you make proper code for it
[12:21] Ubit Umarov: in fact on the c support libs
[12:22] Gavin.Hird @grid.xmir.org:8002: it also alwasy worked on the 32-bit macOS version compiled with Clang
[12:22] Ubit Umarov: long long is a native type
[12:22] Ubit Umarov: at least on this win and linux
[12:23] Ubit Umarov: ll even defines it its own way to avoid complier issues
[12:23] Ubit Umarov: in this case as U64 i think
[12:23] Andrew Hellershanks: Of course they do. :)
[12:24] Ubit Umarov: well up to 63 work fine.. 100 does not :)
[12:24] Ubit Umarov: a fun runtime error
[12:24] Ubit Umarov: well finding was kinda easy
[12:25] Ubit Umarov: 32bit/64bit issues do point to special operations issues
[12:25] Ubit Umarov: pointer aritm the first obvius case
[12:26] Ubit Umarov: then diferent handling of low level ops like <<
[12:26] Ubit Umarov: fun how the compiler seen a bit test
[12:26] Ubit Umarov: to make use of that on intel cpus
[12:26] Ubit Umarov: c# jit does the same now
[12:27] Ubit Umarov: on arm it does need to be a shift and a &
[12:27] Ubit Umarov: if i remember its asm
[12:27] Ubit Umarov: same on mips
[12:27] Ubit Umarov: well details
[12:28] Ubit Umarov: so what more news do you have about opensim?
[12:28] Gavin.Hird @grid.xmir.org:8002: Apple added a special memory mode to the CPU to allow for efficient execution of X86/X64 on the ARM chip
[12:28] Ubit Umarov: bit test is on x86 since ever guess from the controlers
[12:29] Ubit Umarov: don't remember on 8085/z80
[12:29] Gavin.Hird @grid.xmir.org:8002: no
[12:30] Andrew Hellershanks: Those chips only had single bit shifts and AND. I don't recall actual bit test instructions.
[12:30] Ubit Umarov: guess it requeire a barrel shitfter
[12:30] Ubit Umarov: requeires
[12:30] Ubit Umarov: well 8030 had it
[12:31] Ubit Umarov: 8031
[12:31] Ubit Umarov: blablabla
[12:31] Andrew Hellershanks: The 680x0 don't have multi-bit shift, AFAIK. The 68000 certainly doesn't but it does have bit test instructions.
[12:31] Andrew Hellershanks: I've been making use of them.
[12:31] Ubit Umarov: yeap most don't..
[12:32] Andrew Hellershanks: We are now at half past and I have a cat wanting my attention. Any last minute items before we wrap up todays meeting?
[12:32] Ubit Umarov: multibit shift is must
[12:32] Ubit Umarov: and not that complex silicon
[12:32] amvans.Lapis @grid.kitely.com:8002: I just wanted to say hi. I'm thinking about doing my own Opensim World and wanted to start coming to these meetings.
[12:33] amvans.Lapis @grid.kitely.com:8002: Sorry I was so late....putting out fires at work at the same time. :)
[12:33] Ubit Umarov: :)
[12:33] Kayaker Magic: Welcome Amvans.
[12:33] Gavin.Hird @grid.xmir.org:8002: cool
[12:33] amvans.Lapis @grid.kitely.com:8002: Virtual fires
[12:33] Andrew Hellershanks: amvans, anyone with an interest in OpenSim is welcome to attend these meetings.
[12:33] amvans.Lapis @grid.kitely.com:8002: Virtual database fires.
[12:33] amvans.Lapis @grid.kitely.com:8002: Thanks!
[12:33] Kayaker Magic: I recommend getting your feet wet by setting up a region or two on OSGrid first.
[12:34] amvans.Lapis @grid.kitely.com:8002: That's a great idea.
[12:34] Ubit Umarov: can use terrain fill do fry feet
[12:34] Ubit Umarov: to dry
[12:34] amvans.Lapis @grid.kitely.com:8002: LOL
[12:34] Andrew Hellershanks: The hardest part when starting out with setting up a grid is going through all of the settings in the ini files.
[12:34] Ubit Umarov: and those opensim devs keep changing those gezz
[12:34] Andrew Hellershanks: hehe
[12:35] Gavin.Hird @grid.xmir.org:8002: and once that is done the hardest thing is to get rid of the defaul avatar autfit
[12:35] Gavin.Hird @grid.xmir.org:8002 whispers: outfit*
[12:35] Ubit Umarov: yeah to get pretty hair like gavin's
[12:35] amvans.Lapis @grid.kitely.com:8002: I am hoping to get some time to try it out soon. I am sure I'll have questions when I fall on my face.
[12:35] Andrew Hellershanks: One other recommendation is to keep your ini changes in a separate file that can be included. It makes handling upgrading to newer versions of OS easier if ini files changed.
[12:36] Gavin.Hird @grid.xmir.org:8002: the colors on that outfit leave a whole lot to be desired
[12:36] Andrew Hellershanks: amvans, you can also use the mailing list or IRC channel to get help.
[12:36] amvans.Lapis @grid.kitely.com:8002: THanks.
[12:36] Kayaker Magic: I got help from Andrew and Bill (not here today) with my first opensim.ini setup. Bug me and I'll pass that on to you Amvans.
[12:37] amvans.Lapis @grid.kitely.com:8002: Ok.
[12:37] Andrew Hellershanks: amvans, if you don't already know about the yearly Open Simulator Community Conference starts in a couple weeks time.
[12:37] amvans.Lapis @grid.kitely.com:8002: Yes! I have a talk in that
[12:38] amvans.Lapis @grid.kitely.com:8002: About using Mozilla Hubs as a gateway drug for getting people into Opensim
[12:38] Andrew Hellershanks: ok. :)
[12:39] amvans.Lapis @grid.kitely.com:8002: I had a talk in it last year where I beat up my co host in a boxing ring over VR vs. VWs
[12:39] Gavin.Hird @grid.xmir.org:8002: what is Mozilla Hubs?
[12:39] amvans.Lapis @grid.kitely.com:8002: It's a web-based VR platform
[12:39] Gavin.Hird @grid.xmir.org:8002: ok....
[12:39] amvans.Lapis @grid.kitely.com:8002: You can use a desktop version or you can use VR headset to experience it.
[12:40] amvans.Lapis @grid.kitely.com:8002: Its super easy because you go through a web browser but not nearly as interactive as OpenSim
[12:41] Andrew Hellershanks: I need to get going.
[12:41] Andrew Hellershanks: Thank you all for coming. See you again next week.

Personal tools
General
About This Wiki