wthit56

joined 4 months ago
[โ€“] wthit56 1 points 2 months ago

It is a bit "sharey" to be fair ๐Ÿ˜… The tooltip helps in this case.

[โ€“] wthit56 1 points 2 months ago (1 children)

I'm not familiar with the AI chat side of things, so I'll leave it to someone else to help with this.

[โ€“] wthit56 2 points 2 months ago (2 children)

If you reply to the specific comment, it's a lot easier to follow the conversation. I keep having to look at all the comments to try to figure out what you're trying to respond to. There's a swoopy arrow pointing left below each comment; click that and you'll reply directly to that comment.

[โ€“] wthit56 2 points 2 months ago

Okay cool. To be clear, hover the mouse over the image, click the heart icon in the corner. It has various options and things to do there; one of them is sending to a gallery.)

[โ€“] wthit56 2 points 2 months ago

What kind of generator are you talking about? Got a link to the one you're working on so we can take a look?

[โ€“] wthit56 3 points 2 months ago (1 children)

I'm not even sure what an app would be that the site is not. What are your goals for making an "app" for perchance?

[โ€“] wthit56 2 points 2 months ago* (last edited 2 months ago) (2 children)

Well, you can share it in infinite ways, so it's hard to know how to answer that is the thing. Are you asking how to post it to Twitter? Host the image file someplace? Send it in an email? Post it to an AI images Reddit? I don't know where to begin!

I can answer if you have something more specific to ask, but Google will likely have an answer for you if you want to try that too. But you'll probably have to think of something more specific than "share an image with the public," see what I mean?

If you just want to share a generated image with the community on that generator, you can "send to gallery" instead, and it will show for anyone looking at that gallery for that generator. You can't do that with just any image file though--it would have to be done by clicking that button on the generation in the page, after it's generated, rather than downloading and doing something with that image.

[โ€“] wthit56 2 points 2 months ago (2 children)

Thanks for your hard work mate ๐Ÿ‘

[โ€“] wthit56 2 points 2 months ago (1 children)

There's not an override built-in. I've written a plugin generators can use which overrides the mode, but no one uses it for now.

Maybe @[email protected] can consider adding something like this for the defaults at least.

[โ€“] wthit56 2 points 2 months ago (4 children)

Generated AI images are free to use and are not copyrighted. So you are allowed, yes. You can share it however you wish to, there's nothing you're "supposed" to do.

N.S.F.W. stands for "not safe for work." Something you don't want your boss to see you looking at at work--normally referring to sexy stuff.

[โ€“] wthit56 1 points 2 months ago (1 children)

@[email protected] @[email protected] Seems to be a running theme recently. I'm not an AI chat user, so I can't speak to it myself.

[โ€“] wthit56 2 points 2 months ago

It just embeds that generator, so views etc. should work the same I think.

But it doesn't "help" that generator in anyway. There's no ranking or pushing to the top of searches or anything based on views.

4
AI Text Plugin Demo (self.perchance)
submitted 3 months ago by wthit56 to c/perchance
 

Not sure if it's cool to post this here but I made a generator that's basically a demo for ai-text-plugin: https://perchance.org/ai-text-plugin-demo. I don't know who manages that plugin, but maybe it would be useful for learners to use, to visualise how it works in more detail.

 

The normal view's iframe has parent elements with background-color that is commented out seemingly. And a parent #e with background-color:#fff but it's got 0 width so doesn't make any difference. Then the body has background-color:#f6f6f6 which is a light grey. This shows through the iframe I think, so the background of the generator looks grey too.

If you go from there and click "edit" it looks different in the preview. And click "fullscreen" and it still looks different in full-window view.

Here: the iframe has background-color:white on it. The parent #output div has the same. The parent of that #e has the same (though weirdly that element does not fill the size of the window or whatever so it looks like a box to the top-left). And from then on it falls through to the top-level body's grey again.

Ideally, these should not be different for editor-mode view and non-editor-mode view.

2
submitted 3 months ago* (last edited 3 months ago) by wthit56 to c/perchance
 

Clicking the "continue" button starts loading and then just stops. Nothing is added. https://perchance.org/bug-continue-doesn-t-work-894u98#edit

Sometimes if I add something it continues. ๐Ÿคท

This example is very simple. Not sure why it doesn't work. And not sure why it does work on certain existing generators. Though on other existing generators (eg. the demo generators from the ai-text-plugin page).

In one I'm actually working on, that [+] button doesn't reappear either, if I click "continue" or "edit."

Also in my own project "Edit" throws an error:

Cannot read properties of null (reading 'getBoundingClientRect')
> let updateCoverPosition = () => {
> let rect = el.getBoundingClientRect();

> in editAiTextResponseClickHandler(el)
> el is passed as null

> which comes from this.closest('.ai-text-response-ctn')

Edit: I made a test generator to see how different ways of starting the ai() call affects such bugs. Seems using outputTo doesn't show the loading icon, and the edit box just appears at the end of the page which I think isn't intentional.

2
[Request] $onload() => (self.perchance)
submitted 3 months ago by wthit56 to c/perchance
 

Seems like plugins almost always have some sort of setup to go through when they're first used. Really, they'd want to just run that code when first imported. But presumably there is no way creators can do that, currently. As it's such a common use-case, having something like this built-in for plugins would be useful, I think.

 

https://perchance.org/auto-vs-reload-bug-3489734953#edit

It seems if "auto" is activated, it does not fully refresh the page. So things like this, where it adds a DOM element just add more and more DOM elements as changes are made. With the test link above, with auto on change the CSS to background-color instead of color. A new style element will be added to the preview, meaning the body now has color:red and background-color:red. When it should only have the latest styles.

This happens even if there's some flag like .has_css_injected and skips making the style element next time the function is called. As in, it seems the list is rebuilt and a new object is now running, but the page is not rebuilt (properly) and old stuff hangs around in there.

Could possibly be only the <head> that is not properly auto-refreshed, I haven't done extensive testing.

If "auto" is off and "refresh" is clicked, only the one style element is present and only the latest styles are properly applied, as expected.

1
submitted 3 months ago* (last edited 3 months ago) by wthit56 to c/perchance
 

Currently it seems to return the first option. I'm working on some UI that allows you to toggle options on and off, by setting the odds. But because of the way it handles this I'm going to have to proxy over it and overwrite the list in the tree... so then I can return "" when there are no possible options. I feel like it would just make sense if it returned an empty string if there are child options but none are possible.

Edit: For all-impossible options, .selectMany() returns the first item multiple times. And .selectUnique() returns each item in order.

2
[Request] string.raw (self.perchance)
submitted 3 months ago by wthit56 to c/perchance
 

Or .escaped or .plain or whatever you want to call it.

Currently, because string is automatically evaluated, [code] and {options} are processed too. This is pretty annoying if that string is meant to be returned and put into the HTML as-is, not evaluated at all. So I have to find-replace [, ], {, and } characters to escape them all manually.

This could be done with a .raw property on strings, for example--to make it easier for creators to do this. (I'm guessing this would be a fairly common things people need to do, when working on non-trivial plugins, etc.)

2
submitted 3 months ago* (last edited 3 months ago) by wthit56 to c/perchance
 

I feel like saved generators are almost always just trying out the coding, or seeing how things work, or even accidentally saving something. People may not even realise something is "public" by default while working on something they don't want to be out in the world (yet at least).

I think "private" would be a better default setting for newly-saved generators. And would likely cut down on the sheer amount of generators (and possibly junk generators) that hang around on the main generators page.

 

This is frustrating when making certain kinds of plugins. For example, you want to pass in some HTML, but you can't because perchance decides the block isn't code anymore.

Ideally, all code within a [code block] would be ignored until its final ].

Oh while I'm on the topic... Please ignore any [] or {} inside of <script> tags or in things like onclick="" attributes. Would make life a lot easier ;p

3
submitted 3 months ago by wthit56 to c/perchance
 

Maybe there's some way of doing this, not sure. But if you've got some function that returns HTML, and use it like [fn()] in your HTML, then use update(), that function will be called again, right? There's no way of blocking that, as far as I know--which could do things like reset state and such.

Not even sure how you'd implement such a feature. Maybe pass an argument to the function telling it it's updating or something? Or mark the code as only-run-once somehow? [:code run once]? Not sure... Could be useful for certain plug-ins though to avoid users of the plugin accidentally messing it up by using update().

1
submitted 3 months ago* (last edited 3 months ago) by wthit56 to c/perchance
 

It seems to me like this is malformed, but it runs as if the rest is code, up to the end of the option or line... but removing the ].

So something like text^[1]2 means "text" has an odds of 12. And {text^[5]6|other} means the "text" option has an odds of 56. Is it meant to work like that, or should an error/warning be raised? @[email protected]

I only noticed because in my own list/perchance compiler I'm making that check and choosing to raise an error for it.

1
Engine study, part 2 (self.perchance)
submitted 3 months ago by wthit56 to c/perchance
 

I started building my version of the engine and it's going pretty well! I'm doing it quite differently to the original way.

The main thing is, I'm essentially transpiling the source into plain JavaScript--then using a Function constructor to return the built object that's ready-to-go. In theory this transpiled JS could be cached on-server and served for faster start-up times. (I know they're only a few ms anyway, but ya know...)

My focus is on preparing everything as early as possible so that while running, the bare minimum processing has to happen. So then generating stuff is "blazingly fast" as a wise man once said.

But anyway... this post, I just have some suggestions. There are some things that are noted as TODOs in code comments, which is fair enough. But here are a few more that might be nice to add. @perchance

Again, this is all just spitballing as I think about how I'm going to build my perchance-like engine for funsies. So if you're not on-board with some of these, that's totally chill! You do you!

Suggestions

.selectAllPossible

Currently we have .selectAll which specifically gets all "option" children, ignoring odds. This would be a way of getting just those that could be output.

It should probably also take into account consumed items in .consumableList objects. Like a "get the rest" operation if you like.

.consumableList method overloads

Currently all methods and functions handle consumableLists as well as just regular lists. It could be more maintainable (potentially less fiddly), and better for performance if the regular functions didn't have to worry about any of that stuff.

So, when a consumableList is created, it could have its own special versions of whatever methods are required added to override the regular ones--something like that.

Not much gain for creators, but just an idea that might have some advantages.

array.selectAll return a copy

Currently it returns the array itself--which could then be manipulated and changed in code, and would affect the original array because it is the original array.

.selectAll normally sends out a new array object with all the items put into it, for regular nodes. So, doing the same for arrays would be more consistent there, and keep with creator expectations.

And it's simple code anyway, so should be an easy change to make.

Array text transform methods

When I looked, it seemed not all the text transform methods are added to arrays.

I was thinking, as there's an array someplace with all the text transform methods listed, it could be used to automatically add methods for all of those at once--making sure it's consistent with everything else.

Single/Multi-line functions

Programmatically these are the same thing, just functions (with some fanciness, I know). But (at least for me) I do trip up on them from time to time.

Like, I put code on the same line but later want more to it, or just to split it onto multiple lines, etc. But forget that you can either have code on the first line or on the second line--not both.

I think it could work just by letting all functions be single or multiple lines and leave it at that. As functions can't have child items anyway, I don't think this would cause any problems with how the code is built by the engine.

Fewer bugs/misunderstandings, (most likely) simpler code in the engine to build them.

(I also have aspirations to optionally add { on the first line and a single } on the last line of code--making it way easier to parse and just grab all the contained code. But that's a whole other thing... ๐Ÿ˜œ)

view more: โ€น prev next โ€บ