bunny Posts - Answer Overflow

bunny

•Created by bunny on 6/21/2024 in #questions

software cost estimating

That article does not understand software economics. COCOMO is used as a very rough estimate for early development, when most of the work is cookie-cutter code. It is also generally disputed and not viewed as accurate for projecting real effort. For that matter, LOC is not a particularly good metric for assessing a code base: not for assessing concepts of "maintainability" or "cost" or "defect rate" or any other metric of code health. It is often used as a base starting point (i.e., given everything else being identical, a code base 2x as large will cost roughly 2x as much), but all the other factors are often considered more important. "All the other factors" include things like modularity, code complexity (many methods of measurement), token count (similar to line count, but not just measuring lines; i.e., some lines have a LOT of tokens, while other lines have only one token), and more. I used to work for a company that had many patents around concepts of code complexity. We were one of many companies with a "cost estimator" tool, too. And we all knew (and openly admitted) that our estimator (just like all others) was very, very, very rough. I.e., cost could easily be 50% of our estimate or 2x our estimate -- the statistical deviation was wide. Our statistical relevance was so-so at best. Same with other models. Finance people still loved the models because you have to assess cost projections somehow, even when you know the estimates are widely flawed. Side note: this is one of the many "holy grail" targets. If you can make an accurate (good luck) cost projection tool to help organizations identify "cost to complete a software project," then you have a product you can sell for $$. Just don't step into the ring assuming that nobody has tried. There are literally dozens of companies shilling various models, and they all sorta suck. Very wide margins-of-error (statistical deviations). As of a couple years ago, there was not a product in existence that is substantially more accurate than quality engineering managers giving a "guestimate" based on decades of experience. Some companies sell massive reports that combine all of the current estimation methods (we sold our estimates to a couple prominent report-generation companies, like Black Duck), but there is no single "this number is pretty good" solution. At least not as of ~2 years ago; last time I was working in that field.

84 replies

MModular

•Created by bunny on 5/16/2024 in #questions

are we fire yet

Do we have a "are we X yet" website/repo/whatever? Rust's series of "are we web/data/game/etc yet" websites were a big part of helping people pick packages to build in order to help Rust's ecosystem. Perhaps we just need a single "are we fire yet" site that lists stuff. Some of that "stuff" is going to be really foundational packages (regex, data-structures, parsers, etc) and some is going to be higher-level (some kind of web framework, a game engine, etc). I think it would be helpful to map out some needs to help people answer the question:

What can I make (for the greater Mojo ecosystem) that is part of the path toward what I want to have for my own pet-project?

ref: are we web yet are we data yet are we GUI yet are we game yet ...there are many more.

10 replies

MModular

•Created by bunny on 5/15/2024 in #questions

VS-Code local imports

2 replies

MModular

•Created by bunny on 5/15/2024 in #questions

Discord timestamps

Not a question, but rather a post to help others use this Discord feature.

8 replies

MModular

•Created by bunny on 5/14/2024 in #community-showcase

toybox

13 replies

MModular

•Created by bunny on 5/9/2024 in #questions

Trait `Comparable`

I looked around, but do not see an answer so far. Does Mojo have a Trait like Comparable to indicate that a Struct has implemented all of the comparison dunder methods? Something like:

trait Comparable:
    # == equal
    fn __eq__(self, other: Self) -> Bool: ...
    # != not equal
    fn __ne__(self, other: Self) -> Bool: ...
    # > greater than
    fn __gt__(self, other: Self) -> Bool: ...
    # < less than
    fn __lt__(self, other: Self) -> Bool: ...
    # >= greater than or equal
    fn __ge__(self, other: Self) -> Bool: ...
    # <= less than or equal
    fn __le__(self, other: Self) -> Bool: ...

trait Comparable:
    # == equal
    fn __eq__(self, other: Self) -> Bool: ...
    # != not equal
    fn __ne__(self, other: Self) -> Bool: ...
    # > greater than
    fn __gt__(self, other: Self) -> Bool: ...
    # < less than
    fn __lt__(self, other: Self) -> Bool: ...
    # >= greater than or equal
    fn __ge__(self, other: Self) -> Bool: ...
    # <= less than or equal
    fn __le__(self, other: Self) -> Bool: ...

13 replies

MModular

•Created by bunny on 4/30/2024 in #questions

sort with custom `cmp_fn`

In Go, I can easily sort a slice with something like:

sort.Slice(my_slice, func(i, j int) bool {
    return my_slice[i][2] < my_slice[j][2]
})

sort.Slice(my_slice, func(i, j int) bool {
    return my_slice[i][2] < my_slice[j][2]
})

The portion func(i, j int) bool { return my_slice[i][2] < my_slice[j][2] } is an anonymous function (lambda) that is used to determine sort order. Therefore, that quick one-liner (3-liner for readibility) will sort based on the value of index 2. As a result, if my_slice starts as: [ [1, 2, 1], [2, 3, 9], [3, 4, 5] ] then it will sort to: [ [1, 2, 1], [3, 4, 5], [2, 3, 9] ] Looking at the doc page for algorithm.sort, it appears to take a cmp_fn arg (like the above anonymous function). Does anybody have sample code I can peek at for how to actually implement? ...tiny brain is confused. 😊

20 replies

MModular

•Created by bunny on 4/25/2024 in #questions

import_path

This post is not a Q, but rather an A for peeps to search out. I'm abusing this Questions forum as a knowledge base, so to say. In this vid, Shashank refs that the file ~/.modular/modular.cfg's setting mojo.import_path can take comma-sep values to identify multiple import paths. The default value is something like:

[mojo]
import_path = /Users/***/.modular/pkg/packages.modular.com_mojo/lib/mojo

[mojo]
import_path = /Users/***/.modular/pkg/packages.modular.com_mojo/lib/mojo

That path contains a bunch of .mojopkg files (like stdlib.mojopkg, algo, math, etc). As the video says, you can add another path, like this:

[mojo]
import_path = /Users/***/.modular/pkg/packages.modular.com_mojo/lib/mojo,/path/to/packages

[mojo]
import_path = /Users/***/.modular/pkg/packages.modular.com_mojo/lib/mojo,/path/to/packages

So, dir /path/to/packages/ is where I direct the "package" command's output. E.g., mojo package SomePkg -o /path/to/packages/SomePkg.mojopkg. As a result, I can do:

from SomePkg import SomeThing

from SomePkg import SomeThing

I can do that without copying the .mojopkg file into every project that uses it. Of note: there is both a [mojo] and a [mojo-nightly] section in the file ~/.modular/modular.cfg. If you want both stable and nightly to import from the same dir, then you need to add ,/path/to/packages to both sections' respective import_path setting. :mojo: :mojonightly:

6 replies

MModular

•Created by bunny on 4/22/2024 in #questions

Type State Pattern

Does anybody have a code-snippet that demonstrates a standard Type State Pattern in Mojo? For example, a somewhat textbook-example of a traffic light -- please excuse any typos I make in my sloppy hand-jam example.

enum TrafficLight {
    Red,
    Green,
    Yellow,
}

impl TrafficLight {
    pub fn new() -> Self::Green { Self::Red }

    pub fn next(self: Self::Red) -> Self::Green { Self::Green }
    pub fn next(self: Self::Green) -> Self::Yellow { Self::Yellow }
    pub fn next(self: Self::Yellow) -> Self::Red { Self::Red }
}

fn main() {
    let mut light = TrafficLight::new(); // light is Red
    light = light.next();                // light is Green
    light = light.next();                // light is Yellow
    light = light.next();                // light is back to Red
}

enum TrafficLight {
    Red,
    Green,
    Yellow,
}

impl TrafficLight {
    pub fn new() -> Self::Green { Self::Red }

    pub fn next(self: Self::Red) -> Self::Green { Self::Green }
    pub fn next(self: Self::Green) -> Self::Yellow { Self::Yellow }
    pub fn next(self: Self::Yellow) -> Self::Red { Self::Red }
}

fn main() {
    let mut light = TrafficLight::new(); // light is Red
    light = light.next();                // light is Green
    light = light.next();                // light is Yellow
    light = light.next();                // light is back to Red
}

Anyway, does anybody have a snippet of Mojo-style Type State Pattern? Google says "no," but I imagine somebody has a personal snippet they might share.

42 replies

MModular

•Created by bunny on 4/20/2024 in #questions

voice channels

Could we please have a few voice channels in this Discord server? I'd love to just park in a channel, muted, and then unmute to chat with peeps about Mojo as some kind of general voice forum. Because I have issues. 😂

5 replies

Gaming

Programming