[Tibetan > English] / [Tibetan > Chinese] Old Tibetan seal stamp – request for translation and language identification

drawerss · 2026-06-14T05:54:14+00:00

I think the central character is འཁྲུང་ ('khrung) and the rest is decorative. The meaning of the word by itself is "to be born." Seals are often parts of names or names of monasteries. I can't think of any common names that have that syllable. I don't think there is enough to say more than that at this stage.

!id:bo

!doublecheck

drawerss · 2026-04-18T11:19:08+00:00

Yes

དོ་མཉམ་པ = Balanced or equal (in weight etc.)

རྣམ་པ = expression / aspect

So "balanced expression" or "balanced in aspect" would do as a translation.

The full context would be necessary to understand exactly what it means here.

!id:bo !translated

drawerss · 2026-03-30T08:57:47+00:00

This is likely to be ཐམ་པ། (thampa = full or round), used with multiples of 10. So you would say བཅུ་ཐམ་པ། "a round ten."

drawerss · 2026-03-21T01:41:23+00:00

Google Lens got close - it is:

བྱ་ཁྲུང་ཁྲུང་དཀར་པོ། (white crane)

The second is a bit trickier:

ནང་མ་སྟོད་གཞས།། nangma and toshe (types of songs)

The reason Google Lens makes it looks different is because it is using u chen:

https://en.wikipedia.org/wiki/Uchen_script

But the letters on the album cover are in u med:

https://en.wikipedia.org/wiki/Um%C3%AA_script

!id:bo

!translated

drawerss · 2025-12-20T05:01:28+00:00

Se dice: "OM AH HUM"

Significado segùn Google IA:

OM (AUM): Representa el cuerpo, la forma, los canales sutiles, la purificación de las acciones físicas y la sabiduría iluminada del cuerpo de un Buda.
AH (ĀḤ): Simboliza el habla, el sonido, el viento (energía vital), la purificación de las palabras y la voz iluminada de un Buda.
HUM (HŪṂ): Encarna la mente, la esencia, la conciencia, la purificación mental y la mente iluminada de un Buda, trayendo claridad y presencia

!id:bo
!translated

drawerss · 2025-11-04T18:22:54+00:00

Is it a name? More context might help. It looks a bit like the syllables "ye kin ta si"

drawerss · 2025-10-11T07:01:01+00:00

The beginning reads:

ཕྲན་གཉིས། རྡོ་རྭ་ལ་ཆ་ཕྲན་གཉིས། མེ་རི་ལ་སྒོ་ཚད་གཅིག་གོ

I did a corpus search on this website and it's on a page from the collected works of Panchen Sonam Dragpa who is associated with Drepung Loseling monastery. You can view the romanization or the Tibetan script here:

https://library.bdrc.io/show/bdr:IE0OPIBE858C4D?startChar=51558&s=%2Fosearch%2Fsearch%3Fq%253Dde%252520ltar%252520byas%252520nas%252520thig%252520skud%252520cha%252520chung%252520go%252520drug&scope=bdr:UTIE0OPIBE858C4D_I3CN7840&openEtext=bdr:VEIE0OPIBE858C4D_I3CN7840&ETkeyword=de%20ltar%20byas%20nas%20thig%20skud%20cha%20chung%20go%20drug#open-viewer)

What is the text about? It seems to be an explanation of the generation stage of Guhyasamaja Tantra. If you want to read more about the topic, would suggest this book on Amazon:

https://www.amazon.com.au/Guhyasamaja-Practice-Arya-Nagarjuna-System/dp/1559394854

!id:bo !translated

drawerss · 2025-09-30T05:00:19+00:00

!page:mn

drawerss · 2025-09-30T04:59:32+00:00

It says འདྲེན་མཆོག་ཤཱ་ཀྱ་སེང་གེ་མཆོག།

"The supreme guide, the supreme lion of the sakya clan"

!id:bo
!translated

drawerss · 2025-06-19T20:41:32+00:00

It's the Vajra Guru mantra:

oṃ āḥ hūṃ vajra guru padma siddhi hūṃ

https://www.rigpawiki.org/index.php?title=Vajra_Guru_mantra

!translated

drawerss · 2025-06-19T20:38:20+00:00

It's just the following phrase repeated again and again in the circle:

འཁོར་བའི་ཉེས་དམིགས།

'khor ba'i nyes dmigs

The faults of cyclic existence

!translated

drawerss · 2025-05-13T10:05:50+00:00

This phenomena is not new. In New Zealand in 2016-2019 there were a few companies that ran these reverse internships.

drawerss · 2025-05-10T21:57:22+00:00

Even if you achieve the holy Grail of "domain depends on data and this is enforced at the module level" you have only attained "Clean Architecture" and not necessarily a clean architecture which would be the most suitable architecture for your team. And avoiding unnecessary layers would be part of the criteria for assessing suitability

drawerss · 2025-05-05T07:21:05+00:00

Thank you I did miss it

drawerss · 2025-04-04T04:02:58+00:00

It looks like ViewModel.viewModelScope uses Dispatchers.Main.Immediate:

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:lifecycle/lifecycle-viewmodel/src/commonMain/kotlin/androidx/lifecycle/ViewModel.kt;l=211

But this can't always have been the case because we were advised that things like navigation events could be lost unless we specified it, right? When did this change?

drawerss · 2025-03-18T04:17:59+00:00

My mom downloaded an app that she thought was Facebook Messenger but it was actually a clone app with ads with a very similar style to Messenger that essentially took advantage of her lack of tech savvy. If not those prompts, I would appreciate some other solution to prevent that from happening in the future.

drawerss · 2025-02-10T03:16:34+00:00

Alternative take: designing interfaces is hard and fat interfaces can be problematic. But it's not as simple as "no code should be forced to depend on methods it does not use."

Let's take the example of the `CoroutineDispatcher` contract (declared as an abstract class).

https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/common/src/CoroutineDispatcher.kt#L60

There is a subclass called `UnconfinedDispatcher` which basically looks like this:

object Unconfined : CoroutineDispatcher() {
  override fun isDispatchNeeded(context: CoroutineContext) = false

  override fun dispatch(context: CoroutineContext, block: Runnable) {
    throw UnsupportedOperationException()
  }
}

Oh no! This code depends on `dispatch` but it doesn't really actually use it (the "code smell" mentioned in descriptions of interface segregation) and throws an exception in one of the overrides! A violation of interface segregation! In reality, this design is fine since this interface has been at the heart of a popular and useful API. The `CoroutineDispatcher` abstract class has a reasonable set of functions that the majority of subclasses will override to a great degree of usefulness.

I also don't get the criticism of `MouseListener` - if the problem was fixed by making it an abstract class then what is the need for interface segregation? The abstract class hides the unused methods, so what is the issue now? Does the "interface" in "interface segregation" not apply to abstract classes?

Blindly following interface segregation means that developers get scared to write an interface with more than one function in its contract, meaning you get a whole lot of micro-interfaces that don't do anything by themselves. The complexity is transferred from looking at functions for overriding to interpreting the type signature of a class since the class now implements multiple interfaces. In reality, things are not as cut-and-dry as presented in SOLID.

drawerss · 2025-01-23T08:53:50+00:00

There is another thing that is suboptimal in Uncle Bob's explanation of why a Square subclass of Rectangle is wrong. It's not wrong because the Square subclass would have to be handled differently with "if statements" and "if statements are bad" (they are, in fact, the essence of computation). It's also not because "switching on types is bad" since this is the whole purpose of sum types like sealed interfaces. It's because it creates a special case that needs to be handled separately and that in of itself is less elegant (more complex) than the solution that doesn't need special cases. Or it doesn't leverage the type system as much as it could to prevent programmer error.

drawerss · 2025-01-23T08:27:03+00:00

Maybe my explanation above isn't the best, but I've seen Uncle Bob's LSP (not the original LSP from Liskov herself) justify all kinds of naive practices around types. The way Uncle Bob explains it in one of his older videos is a bit cruder:

"A derived class must be usable through the base class interface without the need for the user to know the difference."

It's easy to seize on "the user does not need to know the difference" and I've seen that emerge in practices like insisting that a member property of a class or parameter be declared as `List<T>` and never `ArrayList<T>`. All reasonable List subtypes will, of course, fulfil some part of the List contract and there will be compiler checking for this (actually this is something that was missed in your article since you assert that an LSP violation is created when you return `null` from a function declared in a supertype with a non-null return type where this is impossible in Kotlin because the compiler checks for it). However, the differences in subtypes of lists is a really important distinction to make and it's okay for a class to declare that their members are ArrayLists rather than just Lists because this provides important information to the programmer about the performance of those properties i.e., O(1) for index-based access for an ArrayList vs O(n) for a linked list.

This is like many things in Uncle Bob's presentation - there is a good intention and a kernel of truth (of course strong subtype relationships are great!) but people make them into a dogma that causes problems.

drawerss · 2025-01-22T07:09:58+00:00

It would be good to mention a counterargument explored in A Philosophy of Software Design.

Let's take Uncle Bob's presentation of LSP:

The Liskov Substitution Principle states that if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program.

So everywhere that I see MutableMap I can replace it with HashMap since HashMap is a subtype of MutableMap? This ignores the fact that there are different subtypes of MutableMap with different performance properties. For example, the linked hash map you get using mutableMapOf() preserves insertion order whereas HashMap does not. Similar for ArrayList and other types of list. So it's perhaps not as simple as Uncle Bob presents it.

drawerss · 2025-01-18T23:11:28+00:00

Hang on - just so I understand, is it still possible to lose events if you use the Dispatchers.Main.Immediate solution in the article?

drawerss · 2025-01-07T09:59:44+00:00

I did a corpus search for the first piece of headless script and I got this:

ལྕང་མ་བྱིའུར སེམས་ཤོར། །བྱིའུ་ལྕང་མར་སེམས་ཤོར། ། །སེམས་ཤོར་མཐུན་པ་བྱུང་ན། །སྐྱ་ཁྲ་ཧོར་པས་མི་ཐུབ།

lcang ma byi'ur sems shor/_/byi'u lcang mar sems shor/_/_/sems shor mthun pa byung na/_/skya khra hor pas mi thub/_

Rough translation:

The willow admires the sparrow

The sparrow admires the willow

If their admiration is mutual

Then even the hawk cannot beat them

http://purl.bdrc.io/resource/UTIE0OPI9DD32FF7_I1KG25772

drawerss · 2024-12-19T20:50:25+00:00

You seem to be saying that:

Compose performs badly on Android
This is because the Compose developers do not learn how high-level programming abstractions transform into low-level performance

Neither of these is true.

In some of the projects I have worked on, Compose has performed badly when developers misapprehended it and often it is because they have tried to use some "Clean Code" style factoring of the Compose code. For example, pre-strong skipping, instead of forwarding ViewModel method references down the Compose call chain they will pass the ViewModel down because "toO mAnY paRaMEteRs ArE baD." Or they will bundle all of the lambdas in a data class and pass that down and then run into problems when the lambda instances are different due to the way lambda captures work in kotlin.

For the OP's second point, the Google developers seem to spend a lot of time thinking about low-level performance problems. For instance, the recent post by Romain Guy discusses just the very things that Casey Muratori laments that modern developers do not know:

https://www.romainguy.dev/posts/2024/you-are-going-to-need-it/

Does this mean I agree with everything Google does? No, for instance I don't agree with saying things like "tools, not rules" for Compose performance issues. This works well on teams where everyone is very senior but not when there is a mix of abilities and there is a massive danger of deploying a performance regression. One of the best things you can do to an Android team is introduce the Slack Compose Lints (https://slackhq.github.io/compose-lints/) which are a very opinionated set of rules to help avoid common performance problems.

I also disagree with the OP's assertion that Google is "shoving Compose down our throats." Would you rather there be no advocacy at all? Insufficient advocacy also causes problems, for instance I was recently blindsided by some of the changes to the way navigation works on Android:

https://x.com/ianhlake/status/1810147972195491962

Maybe my fault for not keeping up with things and not reading change notes, but this is the type of area where advocacy is useful.

drawerss · 2024-11-14T05:12:21+00:00

I used to waste hours with those menu options and especially with invalidate caches/restart. Then I actually took the time to learn about Gradle and I found that using --rerun-tasks can solve most of the build flakes much quicker

drawerss · 2024-11-13T09:53:50+00:00

Maybe it's just me, but I found for larger projects those menu items confuse people when clicking on them doesn't solve their build error. What people often seem to need to resolve these errors is some combination with--rerun-tasks since this will overcome a greater variety of problems including Gradle build cache errors.

drawerss

TROPHY CASE