Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 06 09:22
    hiiamboris commented #4158
  • Oct 06 09:19
    hiiamboris commented #4158
  • Oct 06 09:09
    qtxie labeled #4045
  • Oct 06 09:09
    qtxie labeled #3964
  • Oct 06 09:07
    qtxie commented #4158
  • Oct 06 09:05
    qtxie unlabeled #4158
  • Oct 06 09:05
    qtxie labeled #4158
  • Oct 06 09:04
    qtxie commented #4158
  • Oct 06 08:55
    qtxie labeled #4275
  • Oct 06 08:46
    qtxie commented #102
  • Oct 06 08:45
    qtxie commented #102
  • Oct 06 08:43
    qtxie closed #4396
  • Oct 06 08:43
    qtxie commented #4396
  • Oct 06 06:25
    dockimbel closed #5220
  • Oct 06 06:24
    dockimbel labeled #5220
  • Oct 06 06:24

    dockimbel on master

    TESTS: adds regression test for… (compare)

  • Oct 05 18:37
    hiiamboris closed #5223
  • Oct 05 18:23
    Avishri99 opened #5223
  • Oct 05 17:44
    dockimbel commented #5220
  • Oct 05 17:43
    dockimbel commented #5220
Alvydas Vitkauskas
@avitkauskas
red ver 0.6.4
bitbegin
@bitbegin
is it daily version
?
Alvydas Vitkauskas
@avitkauskas
last stable
bitbegin
@bitbegin
you need a latest daily version like this red-03sep19-8b5417f7
Alvydas Vitkauskas
@avitkauskas
ok, i'll try that
Alvydas Vitkauskas
@avitkauskas
Yes, it works with the latest daily! Thanks
Nenad Rakocevic
@dockimbel
@loziniak Thanks for maintaining that GTK page! :+1:
Nenad Rakocevic
@dockimbel
Is it me or the AV issue got better recently? Only Avira and F-Secure remain problematic, and a few other unknown ones.
Nenad Rakocevic
@dockimbel
Strangely, the --no-compress option seems to make no difference on the false detection of the remaining ones.
Petr Krenzelok
@pekr
Did they got better, or did Red changed some low level bits, so they no longer complain?
Nenad Rakocevic
@dockimbel
It's not Red's doing, so I guess most of them fixed/improved their engines. Though my testing is done only using VirusTotal (we don't use any AV on our machines), the behavior of AV installed on end-users machines could differ.
I've submitted a false-positive report to F-Secure. I gave up on Avira a while ago, after sending many reports without getting any feedback.
Dave Andersen
@dander
Have you considered using a code signing certificate? It does cost some money, but I think some AV tools will begin to trust the certificate over time. I'm not sure if there would be a problem with on-the-fly compiled components being unsigned, but those are at least generated locally, rather than from the internet, so they may be more trusted
Nenad Rakocevic
@dockimbel
@dander Sure, we did. First, it's hard to obtain, as you have to go through many online and offline hurdles (being based in China for many years was one of the show-stoppers). Second, it's only for the Red binaries we distribute, not for user-generated ones. For the on-the-fly components, we should replace some of them with precompiled ones in the 0.6.5 release.
Rebol2Red
@Rebol2Red

@toomasv

do gen-hack2 "Just another Red hacker!"
;== [random/seed 2 random "uhJts trnckoe!e rRha dea"]

print [random/seed 2 random "uhJts trnckoe!e rRha dea"]

when printing there is a space before "Just another Red hacker!"
I can't find out why?

Toomas Vooglaid
@toomasv

@Rebol2Red print reduces the argument block, hence:

>> reduce [random/seed 20 random "taskohucRrhdt anr e Jee!"]
== [unset "Just another Red hacker!"]

What's before string adds a space. But:

>> print do [random/seed 20 random "taskohucRrhdt anr e Jee!"]
Just another Red hacker!
Rebol2Red
@Rebol2Red
@toomasv Aha, I did use reduce in the script but not inside the console. I should use the console more often!
Toomas Vooglaid
@toomasv
:+1:
Rudolf Meijer
@meijeru
I notice that type info has been added to all local variables in hashtable.reds. This is worthwhile from a documentation point of view but I guess that to extend this to the whole toolchain would usurp precious manpower. What is the policy to be?
Nenad Rakocevic
@dockimbel
@meijeru The Red runtime library functions should have type descriptions for locals to avoid compiler falling back to 64-bit stack slots for local variables. Not only that wastes stack space, but also creates "holes" where garbage data from previous calls can remain, creating undefined behaviors for the GC.
Rudolf Meijer
@meijeru
I see. Still, it is a tall order to do that for all of them...
Nenad Rakocevic
@dockimbel
@meijeru It is not necessary for "all of them", just for the function that can be on the call stack when the GC is invoked. Anyway, it's a temporary measure that will be superseded by some upcoming new R/S features.
hiiamboris
@hiiamboris

@dockimbel speaking of R/S features, using Red stack from R/S feels like holding a blade by it's edge :) It's filled manually item by item in various parts of code, sometimes recursive code, then gets modified by the many functions you call from that code (and the functions called by those functions). So basically it's impossible to predict what will happen to the stack by just looking at the source. As an example if anybody will be able to follow how the stack works inside do-print in less than 2 hours, I'll applaud him :)

So, can you add a (debug-mode) feature that would check the Red stack (or any data referred to by another pointer) layout declaratively and report if anything's amiss?

Something like this:

#check stack/arguments [some/value1 some/value2 some/value3]
some-func*

(the above would check that stack/top is at least 3 slots above the arguments, and compare it's contents with the provided constants, then call the some-func* that relies on this specific layout)

Alvydas Vitkauskas
@avitkauskas
Hi. Could you please share what is the current status with 64-bit Red? Mac OS Cataline is round the corner. Does that mean I will not be able to run Red apps on my Mac soon?
Gregg Irwin
@greggirwin
@avitkauskas Catalina is a big issue for us, and we've outlined the 64-bit plan, though things can always change. Mac comes first, with some key changes being needed in deep internals (e.g. 64-bit pointers and a decision on cell size), but we can cross compile from 32-bit, which is how we'll bootstrap the move. We need Mach-O 64-bit file format and x64 generation from R/S. Those are the first big pieces. Then all tests have to be updated, then the View engine.
Alvydas Vitkauskas
@avitkauskas
Yea, I imagine how big thing it is to change to 64-bit. What disturbes me is that the talks about the necessity of 64-bit was going around from at leat 2016 (if not much earlier), but still it seems that everyone is caught by surpise. I am totaly new to Red, and I like it very much, I like the idea! But it looks so much endagered by this 64-bit issue. I understand that the core team is really small, so this puts additional presure on the matter. I could only wish you strenght and optimism to deal with that.
Gregg Irwin
@greggirwin
Thanks for the support. It is a big challenge, and we're not caught by surprise so much as having the issue forced. With other big design elements in the works, it's a distraction from that. With these changes, there may be things R/S community members can do to help. If Nenad and Qingtian lay out chunks of "grunt work" or tasks they feel safe in delegating to a couple trusted members, that will help a lot.
And we have to weigh the importance of Catalina users compared to everything else.
Dave Andersen
@dander
I'm not a Mac user, but it made me curious about the rate of adoption. this chart seems to show last year's release getting to around 50% market share over the course of a year. I would expect that to be a faster rate for developers than typical users. Also, though MacOS overall market share appears to be somewhere around 5%, for developers it's much higher ~26%. This is just a from a very brief search, and I have no idea how closely it would reflect the potential Red user pool, so take it for what it is
Alvydas Vitkauskas
@avitkauskas
Yes, that's true, Mac OS newest version adoption rate is always high, and for developers the market share of Macs is really significant, no doubt about that. I am now learning Red and Red/System with the great interest, but - beeing a Mac user - I have to admit having some taste of sand between my teeth because of this 64-bit question :(
Gregg Irwin
@greggirwin
Thanks @dander. Making Red sustainable is a necessary priority, and we're working on plans for that.
BuilderGuy1
@BuilderGuy1
That 5%-ish Mac market share is a "global" number. if you look at smaller regions or groups such as Country or State/Prov then the numbers can be MUCH higher (as you have noted)
I just upgraded my 2008 Mac Pro to Majove (10.14) so I will keep it there for the foreseeable future. I want to keep it "Red-capable" ;-) My 2005 MacBook Pro will also stay at Mojave for awhile so I can use Red and other 32-bit applications (that likely will never see a 64bit version)
BuilderGuy1
@BuilderGuy1
Net Market share shows MacOS at 9.74%
Nenad Rakocevic
@dockimbel
@BuilderGuy1 I have moved your NetMarket link here, as it was spanning over many lines... Please use embedded links in such cases.
@avitkauskas Don't expect the 64-bit support for macOS before the end of the year. In the meantime, you can still use virtualization tools to run Red on macOS after upgrading to 10.15. And we are aware of that change since a long time, but as Gregg said, ensuring sustainability of the whole project takes precedence.
@dander If we consider the red-lang.org visitors, we have Windows: 52%, macOS: 18%, Linux: 10%.
Nenad Rakocevic
@dockimbel
@hiiamboris There is an issue with your commit red/red@375b15f. See my embedded comments. Basically, in its current form, the commit has no effect on the code. So, let me know if you want to change it or if I can roll it back.
Dave Andersen
@dander
Congrats for reaching 4k stars on the Red repo! @dockimbel did you get the 4000th star? 😋
Nenad Rakocevic
@dockimbel
@dander Thanks. 4001st. ;-)
Toomas Vooglaid
@toomasv
:tada: :confetti_ball: :cake: :wine_glass:
lucindamichele
@lucindamichele
Congrats indeed!
Nenad Rakocevic
@dockimbel
Thanks, in the name of all the contributors! :100:
Nenad Rakocevic
@dockimbel

This morning, I stumbled upon an old blog entry from Carl about redefining find on objects. In a nutshell, there's a duplication betweenin and find when used with objects. Carl proposed to repurpose find to search among the values instead of the object's words. That sounds like a useful feature to have, so I made a prototype implementation in Red:

obj: object [a: 4 b: "hi" c: 'hello d: 4]
find obj 4
== a
find obj 'hello
== c

The /part refinement is supported, to start the search from a different word/value pair than the first one, allowing to find all the occurrences of the same value within an object:

i: index? find obj 4
== 1
find/part obj 4 i + 1
== d

index? in Red can be used on words, to return the index of the word in a context. As findreturns a word that is bound to the object, we can extract its index that way, increment it, then use it as argument to find/part to start after c in the object.
Extra features: /case and /same refinements are supported also.

What do you think about it? Should I merge it in master?

hiiamboris
@hiiamboris
I guess it's more informative/useful than just returning true/false given a word.
Nenad Rakocevic
@dockimbel
We currently don't have any direct way to do this search on values within an object. We can use reflectors (words-of and values-of), but they create intermediary blocks, that can become a significant overhead when searching through a tree of objects. OTOH, if we add support for foreach on objects, browsing objects becomes much lighter, though, such searching operation would be way slower than having find handle it at low-level. So it looks like this could be a sweet spot.
Oldes Huhuman
@Oldes
How many MBs it adds? I like it, although I have no idea for which purpose I could use it now.
The part related part is a little bit more difficult to understand.. one have to read it twice. Maybe because I never noticed that index? works with words in Red.