You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Transient Purescript-Text-Encoding is overly burdensome. #20
The transient dependency on the text encoding library is there to provide a very specific use-case that is not general to all users of this library, and thus makes more sense to be removed. Ideally this could be a two stage process where first a new library is released providing the needed functionality, and then the functionality in this library can be removed, alongside a link and explanation that a new library now provides this behavior.
I kind of agree with the "breakout" library idea actually, as I'm considering improving another library I maintain which has minimal behaviour for base64 encoding, and wrapping these dependencies in a library specifically for working with strings, base64, and arraybuffers collectively.
Did you want to preserve some semblance of the string encoding/decoding for this lib here?
If you were to release the stripped down version a la my PR here as another major version, I think I can commit to having a library up by the end of the weekend to provide the now missing functionality, and I could PR your Readme to include a note about what changed and how to resolve the problem.
What do you think?
Important to note I also removed the Show instance as it depended on a node-only inspect.
I'm right in the middle of thoroughly testing my branch - I'll make sure to pull whatever you've changed. I don't have any form of text-encoding integration right now - I ripped out everything, so any upgrades should be smooth, and I haven't touched arraybuffer-types.
I'll give the name some thought. My intent also intends to include working with a wrapped base64 type (still text underneath ofc), but yeah, I'm not fully happy with the name either. If/When I rename though that link will still be valid for a while to find under the new name. Github rename redirects are cozy.
Activity
AlexaDeWit commentedon Dec 6, 2018
Oh crap, this is especially needed as this underlying library is now deprecated.
https://github.com/inexorabletash/text-encoding
In the deriving library I'll want to try and abstract this problem out.... which means back to my old nightmare.
jacereda commentedon Dec 6, 2018
What if you restrict it to UTF-8? There's a small polyfill here that could serve as a starting point:
https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder
AlexaDeWit commentedon Dec 6, 2018
I lack a minimalist isomorphism to do the decode easily available. I don't remember the full history of the work I was doing.
I'm also thinking of working further at erasing the need for a polyfill in the other library, but that is more of a long term goal.
AlexaDeWit commentedon Dec 6, 2018
I kind of agree with the "breakout" library idea actually, as I'm considering improving another library I maintain which has minimal behaviour for base64 encoding, and wrapping these dependencies in a library specifically for working with strings, base64, and arraybuffers collectively.
Did you want to preserve some semblance of the string encoding/decoding for this lib here?
jacereda commentedon Dec 6, 2018
No problem on my side, I have only used binary arraybuffers myself.
AlexaDeWit commentedon Dec 6, 2018
If you were to release the stripped down version a la my PR here as another major version, I think I can commit to having a library up by the end of the weekend to provide the now missing functionality, and I could PR your Readme to include a note about what changed and how to resolve the problem.
What do you think?
Important to note I also removed the Show instance as it depended on a node-only inspect.
jacereda commentedon Dec 6, 2018
Would merging to a temporary branch suffice? @athanclark will probably change the API as well and 2 major bumps could be a bit strange...
AlexaDeWit commentedon Dec 6, 2018
Sure, I can always do my next library using a local fork copied into the directory. Make a branch for me to merge into and I'll update the PR.
jacereda commentedon Dec 7, 2018
I have created https://github.com/jacereda/purescript-arraybuffer/tree/v9 including your PR.
AlexaDeWit commentedon Dec 7, 2018
Cheers to that. So I assume we expect that @athanclark 's work will also end up here as part of the v9 release?
AlexaDeWit commentedon Dec 7, 2018
https://github.com/AlexaDeWit/purescript-arraybuffer-encoding This is where the new library will live btw.
athanclark commentedon Dec 7, 2018
I'm right in the middle of thoroughly testing my branch - I'll make sure to pull whatever you've changed. I don't have any form of text-encoding integration right now - I ripped out everything, so any upgrades should be smooth, and I haven't touched arraybuffer-types.
AlexaDeWit commentedon Dec 7, 2018
Sounds good. My changes also rip out text-encoding completely, so you may have to resolve conflicts if we did it differently.
jacereda commentedon Dec 7, 2018
@AlexaDeWit would -codecs be a better name since it will also have decoding?
jacereda commentedon Dec 7, 2018
or text-codecs...
AlexaDeWit commentedon Dec 7, 2018
I'll give the name some thought. My intent also intends to include working with a wrapped base64 type (still text underneath ofc), but yeah, I'm not fully happy with the name either. If/When I rename though that link will still be valid for a while to find under the new name. Github rename redirects are cozy.
AlexaDeWit commentedon Dec 7, 2018
purescript-arraybuffer-codecs maybe, minus the "text" bit. Is decent.
AlexaDeWit commentedon Dec 7, 2018
https://github.com/AlexaDeWit/purescript-arraybuffer-codecs renamed, I'll die on this hill and all that. <3
jacereda commentedon Jan 22, 2019
I think #23 will take a while.
I cherry-picked your changes to master and published v9.0.0. Thanks.
jacereda commentedon Feb 1, 2019
The v10 branch has been merged to master, tell me if you have any problem with the new API in your -arraybuffer-codecs.